Michel Alexandre Salim michel-slm @facebook Seattle, WA, USA Production Engineer at Meta

michel-slm/aws-portknock 13

Port knocking for AWS security groups

michel-slm/0install-interfaces 3

My 0install interfaces

michel-slm/clj-puzzles 2

Clojure solutions to programming puzzles

michel-slm/blist 1

A list-like type with better asymptotic performance and similar performance on small lists

michel-slm/clojure 1

The Clojure programming language

michel-slm/clojure-contrib 1

Extensions and enhancements to the Clojure libraries.

michel-slm/clojure-mode 1

A mode for emacs that handles clojure

michel-slm/contactbot 1

A microblogging bot for asynchronously updating contact information

michel-slm/0install 0

the core 0install package

michel-slm/anaconda 0

Graphical system installer


started time in 13 hours

issue comment89luca89/distrobox

[Error] can't start a Debian container on Fedora host

PS @alcir I'm more than happy to help get this into Fedora properly, let me know if you want to submit it and I'll review.

I have some workflows that are much simplified by this amazing tool


comment created time in 15 hours

issue comment89luca89/distrobox

[Error] can't start a Debian container on Fedora host

Thanks @89luca89 ! In Fedora, /bin is just a symlink to /usr/bin anyway so it should not matter. I suspect the problem is some of the mangling is to scripts that are meant to run on the Debian side, though, and Debian hasn't made this /usr transition?

AFK now but I'm assuming it's the bin/sh in distrobox-enter that's problematic


comment created time in 16 hours

issue opened89luca89/distrobox

[Error] can't start a Debian testing container

Describe the bug After creating a Debian testing container, using the image URLs listed in, I can't start the container.

To Reproduce

distrobox create --image --name debian-packaging
distrobox enter debian-packaging --verbose

I also tried, the error is similar

Expected behavior It should start

Logs Run the commands with --verbose and post the log here as a file upload Attach also the output of podman logs or docker logs, possibly with --latest flag distrobox-enter.txt

$ podman logs --latest
{"msg":"exec container process (missing dynamic library?) `/usr/bin/entrypoint`: No such file or directory","level":"error","time":"2022-01-18T22:19:48.000323778Z"}
exec container process (missing dynamic library?) `/usr/bin/entrypoint`: No such file or directory

Desktop (please complete the following information):

  • OS: Fedora
  • Version: 35
  • Distrobox version: distrobox-1.2.11-1.fc35.x86_64 from COPR

Additional context It works fine for a CentOS Stream 8 container

created time in 21 hours

issue commentnextcloud/desktop

Build failure on GCC 12 because standard attributes are present in the middle of decl-specifiers

GCC documentation of the change:


comment created time in 4 days

issue openednextcloud/desktop

Build failure on GCC 12 because standard attributes are present in the middle of decl-specifiers

<!-- Thanks for reporting issues back to Nextcloud!

This is the issue tracker of Nextcloud, please do NOT use this to get answers to your questions or get help for fixing your installation. You can find help debugging your system on our home user forums: or, if you use Nextcloud in a large organization, ask our engineers on See also for support options.

Guidelines for submitting issues:

  • Please search the existing issues first, it's likely that your issue was already reported or even fixed.

    • Go to and type any word in the top search/command bar. You probably see something like "We couldn’t find any repositories matching ..." then click "Issues" in the left navigation.
    • You can also filter by appending e. g. "state:open" to the search string.
    • More info on search syntax within github:
  • Please fill in as much of the template below as possible. The logs are absolutely crucial for the developers to be able to help you. Expect us to quickly close issues without logs or other information we need.

  • Also note that we have a that applies on Github. To summarize it: be kind. We try our best to be nice, too. If you can't be bothered to be polite, please just don't bother to report issues as we won't feel motivated to help you. -->

<!--- Please keep the note below for others who read your bug report -->

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Expected behaviour

Nextcloud 3.4.1 should build fine with GCC 12

Actual behaviour

This fails due to GCC 12 "detecting using standard attributes in the middle of decl-specifiers, which is invalid.". build.log and root.log (the latter showing what packages are used for the build) attached.


Steps to reproduce

  1. install Fedora
  2. sudo dnf install fedora-packager
  3. fedpkg clone -a nextcloud-client
  4. cd nextcloud-client
  5. fedpkg srpm && mock ./*.src.rpm

Client configuration

Client version: 3.4.1 <!--- Please try to only report a bug if it happens with the latest version The latest version can be seen by checking --->

Operating system: Fedora Linux (developing on 35, building against Rawhide which has GCC 12)

OS language: US English (but N/A)

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only): nextcloud-client-3.4.1-1.fc36

Installation path of client: N/A

Server configuration


Storage backend (external storage):


<!-- desktop client logs are a hard requirement for bug reports because we don't know how to do magic here :) -->

Please use Gist ( or a similar code paster for longer logs.

  1. Client logfile: Since 3.1: Under the "General" settings, you can click on "Create Debug Archive ..." to pick the location of where the desktop client will export the logs and the database to a zip file. On previous releases: Via the command line: nextcloud --logdebug --logwindow or nextcloud --logdebug --logfile log.txt (See also

  2. Web server error log:

  3. Server logfile: nextcloud log (data/nextcloud.log):

created time in 4 days

pull request commentrekka/meval-rs


any update here? nu-command requires meval, and we have nom 7.1.0 in Fedora so unless we maintain nom 1.x there separately, we can't build Nushell without heavily patching meval


comment created time in 7 days

pull request commentRazrFalcon/roxmltree

chore: Update pretty_assertions to 0.6

Can we use 0.5 on Windows and 0.6 everywhere else?


comment created time in 7 days

issue openednushell/nushell

Consider forking common-path

Related problem

common-path, which nu-data depends on, has not been updated in 3 years, and the upstream repo is no longer present.

Looking at the author's other crates, faclair is also missing a repo, and many of the recent updates involve putting the crates in the public domain.

I've reached out to the author via email, but have not heard back.

Describe the solution you'd like

I asked the author to at least temporarily put the repo back up. If the author responds, perhaps the Nushell project can consider forking it the same way nu-json is maintained here as a fork, and that way we have the development history preserved.

Describe alternatives you've considered

Fallback: just create a new repo and check in the current crate as is.

Additional context and details

This came up during the Fedora package review, when the reviewer noticed that the rand dev-dependency is really old (common-path builds and tests fine with the latest rand), and I tried filing a PR upstream and noticed there's no upstream.

created time in 8 days

pull request commentrpm-software-management/mock

Remove failovermethod=priority from c8s and epel8 templates

These were removed in DNF, and now cause warnings when populating the mock chroot:

But dnf was fixed not to produce these warnings, see this commit ebff6d0 Perhaps you should mention it is a revert.

ah, I did not realize I was reverting something introduced recently, sorry. That would explain why I did not remember seeing this before.

Not sure why I'm seeing this though. I'm on 4.9.0-1.fc35, and looking at the spec I don't see substantial changes from 4.9.0-1.fc34 which is marked as closing


comment created time in 9 days

delete branch michel-slm/nushell

delete branch : rename-cli-splits

delete time in 9 days

issue openednushell/nushell

Bump pretty dependency for nu-source

Related problem

nu-source currently requires pretty 0.5.2, but 0.11.2 is out (0.5.2 is released over 3 years ago).

From upstream's changelog, there's a minor breaking change in v0.7.0, so this might need some testing:

  • Rename space to line and newline to hardline

Describe the solution you'd like

nu-source's Cargo.toml requires a newer version of pretty

Describe alternatives you've considered

No response

Additional context and details

I'm packaging nushell in Fedora, and we generally prefer maintaining a single version of each crate, though sometimes we're forced to keep several versions if there's significant API breakage and we have crates that depend on incompatible versions.

created time in 9 days

issue openedtafia/calamine

Bump quick-xml dependency

calamine is set to use quick-xml 0.19.0, this should probably be at least 0.22.0? It compiles fine with the 0.23.0 alpha in Fedora

created time in 10 days

issue openedjaparic/heapless

v0.7.9 not tagged on GitHub

Please tag this release, thanks! I noticed when trying to package tihs in Fedora as a dependency for

created time in 10 days


started time in 10 days

PR opened nushell/nushell

Update descriptions for crates split out from nu-cli

nu-command and nu-data were split out, but the descriptions still say 'CLI'.

Signed-off-by: Michel Alexandre Salim

+2 -2

0 comment

2 changed files

pr created time in 11 days

create barnchmichel-slm/nushell

branch : rename-cli-splits

created branch time in 11 days

PR opened rpm-software-management/mock

Remove failovermethod=priority from c8s and epel8 templates

These were removed in DNF, and now cause warnings when populating the mock chroot:

Invalid configuration value: failovermethod=priority in /var/lib/mock/epel-8-x86_64-zstd/root/etc/dnf/dnf.conf; Configuration: OptionBinding with id "failovermethod" does not exist

The C8S and EPEL repo definitions no longer set this key.

Signed-off-by: Michel Alexandre Salim

+0 -8

0 comment

2 changed files

pr created time in 12 days

create barnchmichel-slm/mock

branch : cs8-epel-rm-failover

created branch time in 12 days

fork michel-slm/mock

Mock is a tool for a reproducible build of RPM packages.

fork in 12 days

push eventmichel-slm/vagrant-libvirt-boxes

Michel Alexandre Salim

commit sha cb7ea4319fb145a8729cb3e434a0a8460073b162

+ centos/9 Signed-off-by: Michel Alexandre Salim <>

view details

push time in 14 days

issue openedjuhp/fbrnch

RFE: use dnf repoquery dependency data, not spec file

fbrnch seems to be parsing spec files to determine dependencies between packages. This does not work for packaging ecosystems that dynamically compute build requirements during the build -- Python SIG is recommending that and all our Rust packages use dynamic BRs

Right now, this doesn't work, e.g.

$ sudo dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --requires rust-below | grep below
Last metadata expiration check: 0:17:52 ago on Wed 05 Jan 2022 10:51:22 AM PST.
(crate(below-common/default) >= 0.4.1 with crate(below-common/default) < 0.5.0~)
(crate(below-config/default) >= 0.4.1 with crate(below-config/default) < 0.5.0~)
(crate(below-dump/default) >= 0.4.1 with crate(below-dump/default) < 0.5.0~)
(crate(below-model/default) >= 0.4.1 with crate(below-model/default) < 0.5.0~)
(crate(below-store/default) >= 0.4.1 with crate(below-store/default) < 0.5.0~)
(crate(below-view/default) >= 0.4.1 with crate(below-view/default) < 0.5.0~)

fbrnch parallel -n claims these can all be built in parallel though:

❯ fbrnch parallel -n f34 rust-below rust-below-common rust-below-config rust-below-dump rust-below-model rust-below-store rust-below-view                                        
Building parallel layer of 7 packages:                                                                                                                                           
rust-below rust-below-common rust-below-config rust-below-dump rust-below-model rust-below-store rust-below-view                                                                 
(0 more layer left) 

created time in 14 days

issue commentjuhp/fbrnch

Adding %autorelease support

Looking forward to a release that supports this! Coupled with #25 I think I'll have to postpone using fbrnch for my parallel builds


comment created time in 22 days

issue commentjuhp/fbrnch

RFE: adding chainbuild support

alternatively, if fbrnch parallel -n spits out the output in a format that can be easily converted to what fedpkg chain-build takes, I can happily just use fbrnch as the dependency calculator engine


comment created time in 22 days

issue openedjuhp/fbrnch

RFE: adding chainbuild support

Right now fbrnch parallel seems to orchestrate the parallel Koji builds on the client side, rather than getting the Koji server to do a chain-build.

This seems to not be ideal, in case e.g. the build is triggered from a laptop with intermittent network connectivity (e.g. you trigger the build when in a meeting, ETA is 5 hours, and you need to go somewhere else).

Given that fbrnch -n already shows the right build order, and fedpkg chain-build supports parallel builds (by grouping the sequence of parallel buildable packages with the ':' separator), can this support be added?

Ideally fbrnch parallel then keep note of the Koji build ID, and in case it was resumed later, just check on that Koji task so it can create the Bodhi update later even if the computer it's running on was disconnected in-between.

created time in 22 days

issue commentvector-im/element-web

Encrypted by an unverified device while all devices are verified

I'm getting this too on Element Desktop (installed via flatpak from my own messages sent from Fluffy on Android are flagged as red. Cross-signing is enabled and both sides show each other as verified.

Weirdly other people I chat with say messages from both Fluffy and Element Desktop show fine to them.

Element version: 1.9.7 Olm version: 3.2.8 Fluffy version: 1.1.0


comment created time in a month

delete branch michel-slm/Fixit

delete branch : gate-importlib-py36

delete time in 2 months

issue commentmozilla-mobile/fenix

'Copy to Clipboard' option not present when 'Share' is clicked

Same on Pixel 6, Android 12. Please use the native share sheet on Android 10+


comment created time in 2 months

pull request commentInstagram/Fixit

Gate importlib-resources to python_version < '3.7'

see for importlib.resources being part of Python 3.7


comment created time in 2 months