Arch-dev-public September 2013

arch-dev-public@lists.archlinux.org

26 participants
62 discussions

[arch-dev-public] db6 rebuild dropped - new ToDo list
by Andreas Radke 08 Feb '14

08 Feb '14

Due to the license change in db5 (MIT style) to db6 (AGPLv3) we drop the db6 update and will keep db5 in core for now. Berkeley db5 won't see much further updates if any at all. We should check each package that now links to it if that functionality is essentially required. I'm going to remove all db bump related packages from staging repo. I'm also going to revert the ToDo list to incomplete for each pkg for checking if a pkg can be build without db support. On the long run we should move db in a first step to extra and maybe later drop it completely. So go on and fix svn trunk to the old state or rebuild it to testing repo without db support wherever possible without loosing important features and mark the ToDo list. -Andy

5 4

[arch-dev-public] Orphaning Wireshark
by Guillaume ALAUX 22 Oct '13

22 Oct '13

Hi everyone, As the title says, I am going to orphan Wireshark. I do not use it on a regular basis which makes it complicated for me to make decisions on whether to implement this or that for this package. Plus it is far away from my Java skills! If anyone is interested, help yourself. If no one steps forward I could also move it to community. Have fun, Guillaume

5 5

[arch-dev-public] Making !staticlibs the default in makepkg.conf
by Allan McRae 20 Oct '13

20 Oct '13

All this recent talk about static libs reminded me that we added options=(!staticlibs) to makepkg-4.1 to automatically remove them, with the idea of enabling it by default. My plan is: - build pacman with updated makepkg.conf - update devtools to have this in the makepkg.conf - set up a rebuild list The rebuild is to allow people that really need static libraries (toolchain etc) to add options=(staticlibs) to their PKGBUILD, although it will also get other static libraries gone. Any obejctions (from devs and TUs)? Allan

5 7

[arch-dev-public] Orphans
by Alexander Rødseth 09 Oct '13

09 Oct '13

Posting this one here as well (first posted to arch-general), as requested by Gaetan Bisson. In connection with the newly created TODO lists for rebuilds of packages formerly maintained by people that are no longer involved with Arch Linux, I wondered if there would be any objections if I moved the following packages from [community] to AUR: (They are currently unneeded orphans, ref https://www.archlinux.org/devel/reports/unneeded-orphans/). abe aircrack-ng archlinux-artwork archlinux-lxdm-theme bchunk bpython bpython2 cdck cherrytree cmus consonance ekg ekg2 fdupes fssos-nsvs ginac gkrellm gnome-themes-extras lastfmsubmitd libcgns2 luarocks lxinput lxlauncher lxmusic lxshortcut mpdscribble obkey openclonk openocd perlbrew pkgtools pypy3 python2-basemap python2-mpi4py python2-pyproj python2-virtkey python-apsw python-basemap python-bsddb python-html5lib python-mpi4py python-pyproj python-virtkey smokeping synaptiks tremulous v8 vim-buftabs vobcopy xdelta xdelta3 Several, but not all of these, are on the newly created TODO-lists. All of them are "unneeded orphans" (https://www.archlinux.org/devel/reports/unneeded-orphans/). If you wish to adopt one of these, just reply to this email (or adopt it). Objections to moving them should preferrably also lead to someone adopting the orphans. -- Best regards, Alexander Rødseth xyproto / TU

10 17

[arch-dev-public] Git
by Alexander Rødseth 07 Oct '13

07 Oct '13

Hi, As I gather, we all like git better than svn, for a long list of reasons. Are there any objections to switching over from svn to git for repositories for the official packages? Yes, this can not be done in a heartbeat. The tools and documentation needs to be updated and the workflow needs to be tested, but are there objections to starting the transition process? -- Best regards, Alexander Rødseth xyproto / TU

8 9

[arch-dev-public] Dropping mplayer2
by Bartłomiej Piotrowski 04 Oct '13

04 Oct '13

I'd like to drop mplayer2 from our repositories. The last commit has been made in the end of April and upstream failed to make new release during last 3 years. While it's possible to keep it in repositories, I don't see any reason to do so. I recommend switching to community/mpv (which is a great replacement with even better performance) or vanilla mplayer from [extra]. -- Bartłomiej Piotrowski http://bpiotrowski.pl/

5 5

[arch-dev-public] Rewriting dbscripts (packagers should read this!)
by Florian Pritz 01 Oct '13

01 Oct '13

Hi, After having read the recent git thread I've come to the conclusion that we should rework dbscripts before we start working on the package backend (although my proposal works better with git because it uses tags). TLDR: You should care and read it. If you don't I won't care if you later miss features that contradicts my proposal. Note: The text below is more or less a cleaned up brain dump so it's probably not complete and possibly confusing. If so, please tell me. I'm also open for discussion via irc as long as the important points are later sent to the ML. # Goal Decouple dbscripts from svn to make it faster and simpler. Moving lots of packages is awefully slow right now. svn tracks the PKGBUILDS and tags refering to certain PKGBUILDs. dbscripts maintains an internal, separate database which tracks in which repo a given package is (identified by a pkgname and a tag). # Definitions - tag: Identifier for a particular pkgbuild + support files; git tag/svn repos subdir; "$epoch:$pkgver-$pkgrel" - package: A single .pkg.tar.xz file. -debug and split packages count as single packages. # dbscripts DB This is not important to packagers, it's internal to dbscripts and only tracks which packages are in a given repo for history purposes. The db contains files called "$repo/$arch/$pkgname" which contain <<EOF %PKGNAME% $pkgbase %VERSION% $tag EOF The whole tree will be versioned via git. This is just my idea, <https://wiki.archlinux.org/index.php/User:Pierre/pkgdbgit> might be talking about simply extracting the db repo-add creates for pacman and tracking that in git, I don't know. I believe dbscripts wouldn't need a db to perform the functions outlined below so we can talk about this later. # Executables Note: Since releasing/moving/removing to/from any (the arch) doesn't make sense any will be an alias that targets all repos. "db-remove extra any pkg1" will therefore remove pkg1 from i686 and x86_64, similar for "commitpkg -a any ..." which will release to i686 and x86_64. ## commitpkg [-a $arch] (from devtools) - create a tag and upload packages to the server - -any packages default to be released to all arches - if target arch is supplied we only release to one arch (also counts for -any packages) - do we want support for directly supplying the commit message? (commitpkg "update to version 1.2.3") ## commitpkg [-a $arch] pkg1.tar.xz pkg2.tar.xz - if called with arguments it will only release those, nothing else - -any packages will be release to all arches unless -a is used ## db-add $repo $arch pkg1.pkg.tar pkg2.pkg.tar - check if the tag exists in the package repo (extract pkgbase from package) - check if the user has permission to release to the repo - call repo-add on the package ## db-update - call db-add for every package in the user's staging directory ## db-move $srcrepo $dstrepo $arch pkg1 pkg2 - move packages between repos ## db-remove $repo $arch pkg1 pkg2 - call repo-remove # Example pacman, core repo pacman-debug (automatic debug split), core repo pacman-shared (split any arch package), core repo pacman-contrib (normal split), extra repo All these are create by building a single PKGBUILD. db-* scripts still run on the server, but simplicity I'll ignore that below ## Releasing Note: Just create a ./release script in your package repo to do that if a simple foopkg doesn't cut it. - corepkg pacman-xxx.pkg.tar.xz pacman-debug-xxx.tar.xz pacman-shared-xxx.tar.xz - extrapkg pacman-contrib-xxx.tar.xz - db-update ## Removing - db-remove core any pacman pacman-shared pacman-contrib pacman-debug - removes the packages from both arches ## moving from testing to core: - db-move testing core i686 pacman pacman-shared pacman-contrib pacman-debug - moves only i686, leaves x86_64 - to move both arches at once just use any instead of i686

6 9

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 30 Sep '13

30 Sep '13

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 12 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 10 fully signed off packages * 51 packages missing signoffs * 20 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (12 total) == * dialog-1.2_20130928-1 (i686) * iw-3.11-1 (i686) * popt-1.16-7 (i686) * systemd-207-6 (i686) * traceroute-2.0.19-2 (i686) * dialog-1.2_20130928-1 (x86_64) * iw-3.11-1 (x86_64) * popt-1.16-7 (x86_64) * systemd-207-6 (x86_64) * traceroute-2.0.19-2 (x86_64) * s-nail-14.4.2-2 (i686) * s-nail-14.4.2-2 (x86_64) == Incomplete signoffs for [core] (15 total) == * btrfs-progs-0.20rc1.3-1 (i686) 0/1 signoffs * dialog-1.2_20130928-1 (i686) 0/1 signoffs * gummiboot-38-1 (i686) 0/1 signoffs * iw-3.11-1 (i686) 0/1 signoffs * popt-1.16-7 (i686) 0/1 signoffs * systemd-207-6 (i686) 0/1 signoffs * traceroute-2.0.19-2 (i686) 0/1 signoffs * cryptsetup-1.6.2-2 (x86_64) 1/2 signoffs * dialog-1.2_20130928-1 (x86_64) 0/2 signoffs * iw-3.11-1 (x86_64) 1/2 signoffs * lvm2-2.02.102-1 (x86_64) 1/2 signoffs * popt-1.16-7 (x86_64) 0/2 signoffs * systemd-207-6 (x86_64) 1/2 signoffs * texinfo-5.2-1 (x86_64) 1/2 signoffs * traceroute-2.0.19-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (34 total) == * flickrnet-3.7.0.0-1 (any) 0/2 signoffs * asymptote-2.24-2 (i686) 0/1 signoffs * hdf5-1.8.11-1 (i686) 0/1 signoffs * hdf5-cpp-fortran-1.8.11-1 (i686) 0/1 signoffs * hdf5-openmpi-1.8.11-1 (i686) 0/1 signoffs * hplip-3.13.9-2 (i686) 0/1 signoffs * neon-0.30.0-1 (i686) 0/1 signoffs * netcdf-4.3.0-1 (i686) 0/1 signoffs * octave-3.6.4-4 (i686) 0/1 signoffs * opencv-2.4.6.1-3 (i686) 0/1 signoffs * postgresql-9.3.0-3 (i686) 0/1 signoffs * postgresql-old-upgrade-9.2.4-1 (i686) 0/1 signoffs * pycups-1.9.63-1 (i686) 0/1 signoffs * qemu-1.6.0-4 (i686) 0/1 signoffs * rsync-3.1.0-1 (i686) 0/1 signoffs * system-config-printer-1.4.2-1 (i686) 0/1 signoffs * upower-0.9.21-1 (i686) 0/1 signoffs * vigra-1.9.0-6 (i686) 0/1 signoffs * asymptote-2.24-2 (x86_64) 0/2 signoffs * hdf5-1.8.11-1 (x86_64) 0/2 signoffs * hdf5-cpp-fortran-1.8.11-1 (x86_64) 0/2 signoffs * hdf5-openmpi-1.8.11-1 (x86_64) 0/2 signoffs * hplip-3.13.9-2 (x86_64) 0/2 signoffs * neon-0.30.0-1 (x86_64) 0/2 signoffs * netcdf-4.3.0-1 (x86_64) 0/2 signoffs * octave-3.6.4-4 (x86_64) 0/2 signoffs * opencv-2.4.6.1-3 (x86_64) 0/2 signoffs * postgresql-9.3.0-3 (x86_64) 1/2 signoffs * postgresql-old-upgrade-9.2.4-1 (x86_64) 1/2 signoffs * pycups-1.9.63-1 (x86_64) 0/2 signoffs * qemu-1.6.0-4 (x86_64) 1/2 signoffs * rsync-3.1.0-1 (x86_64) 0/2 signoffs * system-config-printer-1.4.2-1 (x86_64) 0/2 signoffs * vigra-1.9.0-6 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * archboot-2013.09-1 (any) 0/2 signoffs * s-nail-14.4.2-2 (x86_64) 1/2 signoffs == Completed signoffs (10 total) == * pambase-20130928-1 (any) * cryptsetup-1.6.2-2 (i686) * lvm2-2.02.102-1 (i686) * syslinux-6.01-4 (i686) * texinfo-5.2-1 (i686) * btrfs-progs-0.20rc1.3-1 (x86_64) * gummiboot-38-1 (x86_64) * syslinux-6.01-4 (x86_64) * upower-0.9.21-1 (x86_64) * s-nail-14.4.2-2 (i686) == All packages in [testing] for more than 14 days (20 total) == * syslinux-6.01-4 (i686), since 2013-07-29 * syslinux-6.01-4 (x86_64), since 2013-07-29 * upower-0.9.21-1 (x86_64), since 2013-07-31 * upower-0.9.21-1 (i686), since 2013-07-31 * postgresql-old-upgrade-9.2.4-1 (i686), since 2013-09-10 * postgresql-old-upgrade-9.2.4-1 (x86_64), since 2013-09-10 * postgresql-9.3.0-3 (i686), since 2013-09-14 * postgresql-9.3.0-3 (x86_64), since 2013-09-14 * vigra-1.9.0-6 (i686), since 2013-09-14 * octave-3.6.4-4 (i686), since 2013-09-14 * vigra-1.9.0-6 (x86_64), since 2013-09-14 * octave-3.6.4-4 (x86_64), since 2013-09-14 * hdf5-1.8.11-1 (i686), since 2013-09-14 * netcdf-4.3.0-1 (i686), since 2013-09-14 * hdf5-1.8.11-1 (x86_64), since 2013-09-14 * hdf5-openmpi-1.8.11-1 (i686), since 2013-09-14 * netcdf-4.3.0-1 (x86_64), since 2013-09-14 * hdf5-cpp-fortran-1.8.11-1 (i686), since 2013-09-14 * hdf5-openmpi-1.8.11-1 (x86_64), since 2013-09-14 * hdf5-cpp-fortran-1.8.11-1 (x86_64), since 2013-09-14 == Top five in signoffs in last 24 hours == 1. bisson - 4 signoffs 2. djgera - 3 signoffs 3. thomas - 2 signoffs

1 0

Re: [arch-dev-public] Git
by Connor Behan 30 Sep '13

30 Sep '13

On 29/09/13 12:25 PM, Alexander R?dseth wrote: > Hi, > > As I gather, we all like git better than svn, for a long list of > reasons. Are there any objections to switching over from svn to git for > repositories for the official packages? One reason to prefer svn is that you can do a non-recursive checkout and only have working copies of the packages you maintain. AFAIK, git does not (want to) support this. > Yes, this can not be done in a heartbeat. The tools and documentation > needs to be updated and the workflow needs to be tested, but are there > objections to starting the transition process?

4 3

[arch-dev-public] heirloom-mailx ==> s-nail
by Gaetan Bisson 29 Sep '13

29 Sep '13

FYI, I'm replacing heirloom-mailx from [core] which has been unmaintained upstream for more than two years by s-nail, a recent fork which is still vastly similar to heirloom-mailx but brings many small features, clean ups, and general improvements. It is currently in [testing]. Cheers. -- Gaetan

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public September 2013