devel December 2020

devel@lists.stg.fedoraproject.org

220 participants
342 discussions

Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
by Ben Cotton 11 Feb '21

11 Feb '21

https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot == Summary == This change will remove make from the default buildroot in Koji and mock. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == ===== Phase 1: Analysis ===== For this change, we will start by creating a list of all packages that have a build-time dependency on make. This will be done by analyzing spec files and also by rebuilding all packages in Fedora with make removed from the buildroot to see which packages fail to build. Once we have this list, we will remove packages that already have BuildRequires:make in their spec file, and this final list[1] will be all the packages that need to be updated in Phase 2. [1] https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br… ===== Phase 2: Package Updates ===== Once we have the list of packages that need to be updated, we will proceed with adding BuildRequires: make to all spec files that require it. This new BuildRequires will be added to the line after the last BuildRequires in the spec file. The release number for packages will '''*not*''' be incremented for this change. The spec file updates will be automated and changes will be pushed directly to dist-git once they are ready. ===== Phase 3: Update Buildroot ===== Once package spec files have been updated, then we can proceed with removing make from the BuildRoot. This will be done by removing make from the build group in Koji and by removing make from the buildsys-build group in comps (fedora-comps). In order to avoid issues with Koschei, this change will need to be made as close as possible to the start of the mass rebuild. If possible, we will try to first remove make from the mass rebuild side-tag and then remove it from rawhide after the rebuild completes. ===== Phase 4: Monitor Failures ===== Once all the changes are in place, we will continue to monitor koji builds to see if there are any failures related to this change. We expect that the analysis done in Phase 1 would give us the complete list of packages that need to be updated, but it is always possible that something will be missed. == Feedback == * Removing make from the Buildroot without rebuilding the packages first has the potential to cause mass failures in Koschei. This is because Koschei builds from the latest SRPM and not from dist-git. We can minimize this problem by removing make from the buildroot as close as possible to the mass rebuild. The proposal has been updated now to account for this issue. == Benefit to Fedora == Based on my research[1], Fedora Rawhide has 22,309 packages, and there are approximately 10,378 packages that either use make explicitly or fail to build when make is removed form the buildroot. This means that there are around 11,931 packages that don't need make. Removing make from the BuildRoot will reduce the network traffic, download times, and disk usage for these builds in Koji and also for users doing builds with mock. Removing make (and its dependencies) will: * Reduce the BuildRoot download size by: 7.3 MB [2]: ** make: 539k ** gc: 104k ** guile22: 6.6M ** libtool-ltdl: 36k * Reduce the BuildRoot install size by; 46 MB [2]: ** make: 1.6M ** gc: 229k ** guile22: 44M ** libtool-ltdl: 71k [1] https://github.com/tstellar/fedora-change-make-buildroot [2] Package sizes are from the x86_64 packages. == Scope == * '''Proposal owners:''' Tom Stellard * '''Package Maintainers:''' Fedora package maintainers should report bugs if they think there is a problem caused by this change, but otherwise there will be no action required by them. * '''Proven Packager:''' The proposal owner will need to either apply for provenpackager status or get the help of someone with provenpackager status in order to make the spec file changes that are required. * '''Release engineering:''' [https://pagure.io/releng/issue/9829 #9829] (a check of an impact with Release Engineering is needed) * '''Policies and guidelines:''' The packager guidelines will need to be updated to mention that BuildRequires: make is now required for all packages that need make. * '''Trademark approval:''' N/A (not needed for this Change) * '''Alignment with Objectives:''' This aligns with the Fedora Minimization [https://pagure.io/minimization/issue/12 objective]. == Upgrade/compatibility impact == This should not impact upgrades. == How To Test == This change can be tested by rebuilding affected packages. The goal is to complete this before the mass rebuild to ensure maximum testing coverage. == User Experience == Fedora users will not notice any difference with this change. This will only impact Fedora package maintainers. == Dependencies == gcc < 11 will fail if the -flto=auto option is used when make is not installed. Phase 3 cannot be completed until gcc 11 lands in rawhide, but Phase 1 and Phase 2 are not blocked by this. == Contingency Plan == * '''Contingency mechanism:''' If we discover critical issues during phase 4, then Fedora Release Engineering will need to re-add make into the buildroot. * '''Contingency deadline:''' 2021-02-23 (F34 Beta Freeze) * '''Blocks release?''' No * '''Blocks product?''' No == Documentation == The packager guidelines will need to be updated to mention that BuildRequires: make is now required for all packages that need make. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

23 56

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

our containers with alias vim=vi
by clime 10 Feb '21

10 Feb '21

Hello, could Fedora and CentOS containers for docker and podman come with `alias vim=vi` in ~/.bashrc? I would very much welcome it as I am used to type vim everywhere but if vi starts instead I am happy too. I know that the solution is to create a customized container but often I want to try something on vanilla containers from the whole range. Didn't want to write about this first but maybe there are more people with the same problem. clime

9 24

Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
by Ben Cotton 05 Feb '21

05 Feb '21

https://fedoraproject.org/wiki/Changes/RPMCoW == Summary == RPM Copy on Write provides a better experience for Fedora Users as it reduces the amount of I/O and offsets CPU cost of package decompression. RPM Copy on Write uses reflinking capabilities in btrfs, which is the default filesystem in Fedora 33. == Owners == * Name: [[User:malmond|Matthew Almond]], [[User:dcavalca|Davide Cavalca]] * Email: malmond(a)fb.com, dcavalca(a)fb.com == Detailed description == Installing and upgrading software packages is a standard part of managing the lifecycle of any operating system. For the entire lifecycle of Fedora, all software is packaged and distributed using the RPM file fomat. This proposal changes how software is downloaded and installed, leaving the distribution process unmodified. === Current process === # Resolve packaging request into a list of packages and operations # Download and verify new packages # Install and/or upgrade packages sequentially using RPM files, decompressing, and writing a copy of the new files to storage. === New process === # Resolve packaging request into a list of packages and operations # Download and '''decompress''' packages into a '''locally optimized''' rpm file # Install and/or upgrade packages sequentially using RPM files, using '''reference linking''' (reflinking) to reuse data already on disk. The outcome is intended to be the same, but the order of operations is different. # Decompression happens inline with download. This has a positive effect on resource usage: downloads are typically limited by bandwidth. Decompression and writing the full data into a single file per rpm is essentially free. Additionally: if there is more than one download at a time, a multi-CPU system can be better utilized. All compression types supported in RPM work because this uses the rpm I/O functions. # RPMs are cached on local storage between downloading and installation time as normal. This allows DNF to defer actual RPM installation to when all the RPM are available. This is unchanged. # The file format for RPMs is different with Copy on Write. The headers are identical, but the payload is different. There is also a footer. ## Files are converted (“transcoded”) locally during download using <code>/usr/bin/rpm2extents</code> (part of rpm codebase). The format is not intended to be “portable” - i.e. copying the files from the cache is not supported. ## Regular RPMs use a compressed .cpio based payload. In contrast, extent based RPMs contain uncompressed data aligned to the fundamental page size of the architecture, e.g. 4KiB on x86_64. This alignment is required for <code>FICLONERANGE</code> to work. Only files are represented in the payload, other directory entries like symlinks, device nodes etc are constructed entirely from rpm header information. Files are referenced by their digest, so identical files are de-duplicated. ## The footer currently has three sections ### Table of original (rpm) file digests, used to validate the integrity of the download in dnf. ### Table of digest → offset used when actually installing files. ### Signature 8 bytes at the end of the file, used to differentiate between traditional RPMs and extent based. === Notes === # The headers are preserved bit for bit during transcoding. This preserves signatures. The signatures cover the main header blob, and the main header blob ensures the integrity of data in two ways: ## Each file with content has a digest. Originally this was md5, but today it’s usually sha256. In normal RPM this is only used to verify the integrity of files, e.g. <code>rpm -V</code>. With CoW we use this as a content key. ## There is/are one or two digests (<code>PAYLOADDIGEST</code> and <code>PAYLOADDIGESTALT</code>) covering the payload archive (compressed cpio). The header value is preserved, but transcoded RPMs do not preserve the original structure so RPM’s pre-installation verification (controlled by <code>%_pkgverify_level</code> will fail. <code>dnf-plugin-cow</code> disables this check in dnf because it verifies the whole file digest which is captured during download/transcoding. The second one is likely used for delta rpm. # This is untested, and possibly incompatible with delta RPM (drpm). The process for reconstructing an rpm to install from a delta is expensive from both a CPU and I/O perspective, while only providing marginal benefits on download size. It is expected that having delta rpm enabled (which is the default) will be handled gracefully. # Disk space requirements are expected to be marginally higher than before: all new packages or updates will consume their installed size before installation instead of about half their size (regular rpms with payloads still cost space). # <code>rpm-plugin-reflink</code> will fall back to simple file copying when the destination path is not on the same filesystem/subvolume. A common example is <code>/boot</code> and/or <code>/boot/efi</code>. # The system will still work on other filesystem types, but will ''always'' fall back to simple copying. This is expected to be slightly slower than not enabling CoW because the source for copying will be the decompressed data. # For systems that enable transparent filesystem compression: every file will continue to be decompressed from the original rpm, and then transparently re-compressed by the filesystem. There is no effective change here. There is a future project to investigate alternate distribution mechanics to provide parallel versions of file content pre-compressed in a filesystem specific format, reducing both CPU costs and I/O. It is expected that this will result in slightly higher network utilization because filesystem compression is purposely restricted to allow random I/O. # Current implementation of <code>dnf-plugin-cow</code> is in Python, but it looks possible to implement this in <code>libdnf</code> instead which would make it work in <code>packagekit</code>. === Performance Metrics === Ballpark performance difference is about half the duration for file download+install time. A lot of rpms are very small, so it’s difficult to see/measure. Larger RPMs give much clearer signal. (Actual numbers/charts will be supplied in Jan 2021) === Terminology === * '''Copy on Write (CoW)''' is a broad description of any technology that reduces or eliminates data duplication by sharing the data behind the scenes until one of the references makes changes. This has been a cornerstone technology in memory management in Unix systems. Here we are using it to specifically reference Copy on Write as supported in modern filesystems, e.g. btrfs, xfs and potentially others. * '''Reflink''' is the verb for duplicating stored data on a filesystem. See [https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html ioctl_ficlonerange(2)] for the specific call we use on Linux * '''Extent''' (based RPMs) refers to how payload file data is stored in within an RPM. Normal RPMs simply contain a compressed CPIO archive. Extent based RPMs contain the raw data uncompressed, which can be referenced with reflink. == Benefit to Fedora == Faster package installs and upgrades == Scope == * Proposal owners: ** Merge changes to rpm, librepo to enable capabilities ** Add dnf-plugin-cow to available packages ** Test days ** Aid with documentation * Other developers: ** rpm, librepo: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9914 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None, RPM with CoW is not enabled by default. Upgrades with <code>keepcache</code> in dnf.conf will be able to use existing packages, but it will not convert them. This only happens at download time. If a system is configured to keep packages in the cache (<code>keepcache</code> in <code>dnf.conf</code>) and <code>dnf-plugin-cow</code> is removed then the packages will be unusable. Recommend <code>dnf clean packages</code> to resolve this. == How to test == Enable RPM with CoW with <pre>$ sudo dnf install dnf-plugin-cow ... $ sudo dnf install hello ... $ hello Hello, world!</pre> There should be no end user visible changes, except timing. == User experience == No anticipated user visible changes in this change proposal. This makes the feature available, but does not enable it by default. == Dependencies == # A copy-on-write filesystem; this Change is primarily targeting btrfs, but RPM with CoW should work with XFS as well (untested) # Most package install paths and the dnf package cache on the same filesystem / subvolume. # <code>rpm</code> with Copy on Write patch set: https://github.com/malmond77/rpm/tree/cow # <code>librepo</code> with transcoding support: https://github.com/malmond77/librepo/tree/transcode_cow # dnf-plugin-reflink (a new package): https://github.com/facebookincubator/dnf-plugin-cow/ == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream, skip <code>dnf-plugin-cow</code> * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == Documentation will be available at https://github.com/facebookincubator/dnf-plugin-cow in the coming weeks == Release Notes == RPM with CoW is not enabled by default. To enable it: <pre>$ sudo dnf install dnf-plugin-cow</pre> -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

27 70

Fedora 34 Change: Ignore Anaconda kernel boot parameters without 'inst.' prefix (System-Wide change)
by Ben Cotton 02 Feb '21

02 Feb '21

https://fedoraproject.org/wiki/Changes/Ignore_Anaconda_kernel_boot_paramete… == Summary == Right now Anaconda allows usage of boot options both with the 'inst' prefix (inst.stage2=) and without (stage2=). We would like to ignore the use of Anaconda kernel boot parameters which do not contain the 'inst.' prefix. == Owner == * Name: [[User:jkonecny| Jiří Konečný]] * Email: <jkonecny(a)redhat.com> == Detailed Description == Anaconda allows you to use kernel boot parameters with and without the 'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying boot parameters without the 'inst' prefix has not been recommended for years and has been deprecated since Fedora 33. We (Anaconda team) would like to make it an official requirement now that users must specify the 'inst.' prefix all the time. The reason for this is frequent parameter conflicts with other projects. We already had a few issues with conflicts in the past, such as if the user ran an installation with `debug`. In that case the installation boot would enable debug mode for the kernel and also for Anaconda which is probably not what the user intended. Another reason is to make it readable at first glance what belongs to Dracut (rd.), kernel (no prefix) or Anaconda (inst.). == Feedback == We have sent mail about doing the deprecation on Fedora 33. The only issue there was why the prefix is 'inst.' and not 'anaconda.'. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… == Benefit to Fedora == This change should make crystal clear what kernel boot parameters are processed by the Anaconda installer. It will also avoid conflicts with other kernel boot parameters. == Scope == * Proposal owners: Remove support to process arguments without the 'inst.' prefix and require the 'inst.' prefix for kernel boot parameters consumed by Anaconda. * Other developers: All configurations using the not-recommended solution without prefix will have to change the invocation of the kernel boot options consumed by Anaconda. These users are already warned since Fedora 33 after boot. This should not be a problem for ISOs we ship because they already use the recommended 'inst.' prefix everywhere. However, it will probably touch some custom PXE configurations and other custom ISO configurations which are prone to this, because users often want to save typing and not explicitly write the 'inst.' prefix. Fortunately, most of these configuration changes shouldn't be that hard to change. * Release engineering: [https://pagure.io/releng/issue/9889 #9889] * Policies and guidelines: This should not be required. All the documentation should use the recommended 'inst.' prefix already. * Trademark approval: No (not needed for this Change) * Alignment with Objectives: No == Upgrade/compatibility impact == If your custom infra configuration is not updated then new Fedora installations could not install correctly. Most probably the ISO will not boot (use of 'stage2=') or your repositories won't be used (use of 'repo='). == How To Test == # You need a Virtual Machine and ISO for testing. # Boot the installation using the ISO and try Anaconda specific kernel boot parameters. See here to find out the list https://anaconda-installer.readthedocs.io/en/latest/boot-options.html. # Parameters without the prefix should be ignored and with the prefix should be used. == User Experience == Users of Fedora official ISOs should not be impacted because all the Fedora official ISOs should already use the recommended prefix. == Dependencies == Don't know about any packages impacted by this change. == Contingency Plan == * Contingency mechanism: The Anaconda team will revert code changes and get back support for boot parameters without the 'inst.' prefix. * Contingency deadline: Final Freeze * Blocks release? No * Blocks product? This won't require changes for any specific product. == Documentation == I don't think we need to document this change other than in Release Notes. As mentioned before, the solution without 'inst.' prefix has not been recommended for years and it should not be used anywhere in the official documentation. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

2 1

What is the most time consuming task for you as packager?
by Miroslav Suchý 29 Jan '21

29 Jan '21

I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear yours. What you - as Fedora packager - find most time consuming on packaging? Where you will welcome more simplicity or automation? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

30 66

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
by Stephen Gallagher 29 Jan '21

29 Jan '21

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. [1] https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Com…

19 62

Chromium built in rawhide does not render most strings
by Tom Callaway 26 Jan '21

26 Jan '21

Okay, this one has me stumped. Any chromium package I build through rawhide refuses to render most of the strings. At first, I thought this was gcc 11, but then I noticed that the first build with this problem was built before GCC 11 landed in rawhide (the compiler was the same n-v-r as the one in Fedora 33). Next, I thought it must be due to a newer system component that Chromium uses dynamically, but I was able to disprove that by installing the Fedora 33 build (same version-release) into a Rawhide VM, and it works fine. Google Chrome also works fine in rawhide. It seems that this must be something that is contained within chromium, that when built in rawhide, builds broken. Here's a screenshot of what it looks like: https://twitter.com/spotfoss/status/1338918235719299072/photo/1 Note that some text strings are rendering (in the UI, in the "search box"), but most of them are not (the "HTML5Test" text below the icon, all of the strings in the developer console). Chromium has a lot of bundled components, so it is usually fairly resistant to system changes. There are no differences between how Chromium builds (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use %{optflags}, so the compiler flags are equivalent. Could this be due to some quirk of binutils in the way chromium gets linked in rawhide? Is there something else unique to how packages are built in rawhide right now? Are any other rawhide packages having similar string issues? Here are some builds for comparison: Fedora 34: Chromium 87.0.4280.88 (built against GCC 11): https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738 Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33): https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036 Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works in rawhide): https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036 Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken) https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476 Thanks in advance, ~spot

10 37

In which order does ELN build packages, what build root is it using?
by Mark Wielaard 25 Jan '21

25 Jan '21

Hi, I couldn't build elfutils because of an annobin bug that showed up on ppc64le. Nick was nice enough to fix it and push a new annobin version: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e So I could build elfutils again: https://bodhi.fedoraproject.org/updates/FEDORA-2020-06dafb46c1 But now I am getting notices about the ELN build failures: https://koji.fedoraproject.org/koji/buildinfo?buildID=1613859 Which is clearly because it doesn't have the new annobin package. Is this something to worry about? Will ELN resync and re-try the build automatically? Or do I somehow need to take action to get ELN buildroot synced with fedora/rawhide again? Thanks, Mark

5 7

List of long term FTBFS packages to be retired in February
by Miro Hrončok 25 Jan '21

25 Jan '21

Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 34 approximately one week before branching (February 2021). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails… Note that some listed packages are orphaned and hence may be retired even sooner. The packages in rawhide were not successfully built at least since Fedora 32. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf… If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers Latest build =============================================================================== VirtualGL gsgatlin Fedora 31 boo elsupergomez, orphan, tpokorra Fedora 31 gmpc orphan Fedora 31 jboss-servlet-2.5-api dmoluguw, orphan Fedora 31 js-html5shiv orphan Fedora 31 js-respond orphan Fedora 31 nodejs-info-symbol orphan Fedora 31 nodejs-interpret nodejs-sig, orphan Fedora 31 nodejs-net-browserify-alt orphan Fedora 31 nodejs-win-spawn nodejs-sig, orphan Fedora 31 rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31 sugar-flipsticks callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-getiabooks callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-infoslicer callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31 sugar-ruler callkalpa, chimosky Fedora 31 sugar-starchart callkalpa, chimosky, orphan Fedora 31 sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31 tuxbrewr sugar-visualmatch chimosky, orphan Fedora 31 sugar-yupana callkalpa, chimosky, orphan Fedora 31 The following packages require above mentioned packages: Depending on: js-html5shiv (1) copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup) copr-frontend-1.171-1.fc34.noarch requires js-html5shiv Depending on: nodejs-info-symbol (2) nodejs-log-utils (maintained by: orphan) nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol) nodejs-time-diff (maintained by: orphan) nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol) Depending on: nodejs-interpret (1) nodejs-shelljs (maintained by: fab, nodejs-sig, patches) nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret) Affected (co)maintainers (directly and indirectly): callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks, sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart, sugar-getiabooks clime: js-html5shiv copr-sig: js-html5shiv dmoluguw: jboss-servlet-2.5-api dturecek: js-html5shiv elsupergomez: boo fab: nodejs-interpret frostyx: js-html5shiv gsgatlin: VirtualGL maxamillion: rubygem-net-ssh-multi msuchy: js-html5shiv nodejs-sig: nodejs-win-spawn, nodejs-interpret patches: nodejs-interpret pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides, sugar-infoslicer, sugar-getiabooks praiskup: js-html5shiv tdawson: rubygem-net-ssh-multi tpokorra: boo tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks

4 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2020