Complete the port of flatpak to appstream from appstream-glib
a project by ldragon
Updated almost 3 years ago. 1 hackers ♥️. 1 follower.

Project Description

Currently flatpak uses appstream-glib to parse and generate appstream files however, appstream-glib is no longer maintained and this has resulted in many features not being propagated to flatpak. There is currently 2 prs porting flatpak & flatpak-builder to appstream.

Goal for this Hackweek

The goal would be to finish the last mile and ensure that the repo's produced and 1:1 or at least close enough to complete the switch.

Resources

https://github.com/flatpak/flatpak/pull/4904

https://github.com/flatpak/flatpak-builder/pull/418

Join this project

Looking for hackers with the skills:

flatpak c appstream

This project is part of:

Hack Week 22

Activity

  • almost 3 years ago: ldragon liked this project.
  • almost 3 years ago: ldragon added keyword "c" to this project.
  • almost 3 years ago: ldragon added keyword "appstream" to this project.
  • almost 3 years ago: ldragon added keyword "flatpak" to this project.
  • almost 3 years ago: ldragon started this project.
  • almost 3 years ago: ldragon originated this project.


    • Comments

    • ldragon
      almost 3 years ago by ldragon | Reply

      Implemented and prs have been sent upstream (flatpak and flatpak-builder)

    Similar Projects

    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources

    Smart lighting with Pico 2 by jmodak

    Description

    I am trying to create a smart-lighting project with a Raspberry Pi Pico that reacts to a movie's visuals and audio that involves combining two distinct functions: ambient screen lighting(visual response) and sound-reactive lighting(audio response)

    Goals

    • Visuals: Capturing the screen's colour requires an external device to analyse screen content and send colour data to the MCU via serial communication.
    • Audio: A sound sensor module connected directly to the Pico that can detect sound volume.
    • Pico 2W: The MCU receives data fro, both inputs and controls an LED strip.

    Resources

    • Raspberry Pi Pico 2 W
    • RGB LED strip
    • Sound detecting sensor
    • Power supply
    • breadboard and wires

    Port OTPClient to GTK >= 4.18 by pstivanin

    Project Description

    OTPClient is currently using GTK3 and cannot easily be ported to GTK4. Since GTK4 came out, there have been quite some big changes. Also, there are now some new deprecation that will take effect with GTK5 (and are active starting from 4.10 as warnings), so I need to think ahead and port OTPClient without using any of those deprecated features.

    Goal for this Hackweek

    • fix the last 3 opened issues (https://github.com/paolostivanin/OTPClient/issues/402, https://github.com/paolostivanin/OTPClient/issues/404, https://github.com/paolostivanin/OTPClient/issues/406) and release a new version
    • continue the rewrite from where we left last year
    • if possible, finally close this 6 years old issue: https://github.com/paolostivanin/OTPClient/issues/123