[TWiR] Call for Participation

the-way has some beginner issues:


Happy to mentor!

1 Like

Would it be possible to add this issue about heed on the next TWIR blog post, please? :slight_smile:

1 Like

Unsoundness in the time crate which can cause an unexpected segfault. User who noticed the issue notes that it may be necessary to reimplement this function entirely in Rust, rather than relying on libc. Given that I'm by no means qualified to do this (as I rarely program in C, and never with OS-level APIs), it's probably best for someone else to take this on.

1 Like

We need to get this issue going with help some help:

1 Like

Could you guys include this issue in the next blog post?

1 Like

Would love to see https://github.com/iliekturtles/uom/issues/223 included in the next TWiR.

1 Like

It would be great if you could include this list of good first issues in the next TWiR: https://github.com/AaronErhardt/Triox/labels/good first issue

1 Like

I'm not entirely sure this fits the Call for Participation, but I figured I'd throw this out there as some people have suggested I do so.

I am currently attempting to add support for the Windows OpenSSH ssh-agent to libssh2, the SSH library used by many Rust programs, including Cargo. My end goal is to support the Windows OpenSSH ssh-agent in Cargo. The main blocker right now to merging support is the maintainers' lack of knowledge and experience with Windows preventing them from comfortably reviewing the code.

I would ask anyone with experience programing on Windows in C to take a look at this PR, and leave a code review. I would deem this a easy to medium task.

2 Likes

Hi !

I'd like to call for contributions for scaphandre, a power consumption measurement agent to help find "energy blackholes" in tech projects and thus make IT more sustainable. :deciduous_tree:

The why of the project is better described here.

scaphandre.small.cleaned

New contributors would be of great help. There are several improvements and tasks to be achieved that can be found in the issue section. Those estimated as easiest are highlighted.

The roadmap is also publicly available. To mention some features that we would like to implement in a near future:

  • Enabling sending power consumption data in monitoring toolchains like Warp10 or Riemann (It's already possible to collect the data from prometheus)

  • Enable tracking power consumption of processes in virtual machines running other hypervisors than Qemu/KVM (there's already a proof of concept for this one, that needs to be improved too :slight_smile: ).

  • Providing a way to estimate power consumptions of virtual machines hosted by cloud providers, when no access to hardware metrics is provided. (a source of inspiration for that particular feature may be cloud-jewels...)

And so on...

:construction_worker_woman: :construction_worker_man: There is a lot of interesting, challenging work to be done. Moreover, this is for a greater cause: to contribute to a more sustainable tech industry and thus help have a better future. Any contribution (not only code) would be celebrated and warmly welcomed. I precise that it is a great deal for us to initiate a community around that project that is kind and respectful to anyone and any effort. The code of conduct of the rust community matches a lot of our values and this project will be respectful of that spirit. Mutual respect and understanding are key values in this project. :dove:

I wish a nice and inspiring open source journey to all the wonderful rust community and I hope to see some of you come and say hi sometime :grinning:

(A Gitter room is available for further discussions.)

3 Likes

I am working on the community space for https://rC3.world and I am looking for someone that would like add a bit of art:
https://github.com/ccc-rustaceans/badges-artwortk

More information is here: rC3 Assembly @ CCC congress

Cheers,
Stefan

1 Like

Got a refactoring issue that shouldn't be too hard in heck:

The js_int crate also has some easy issues to fix:

1 Like

rust design pattern book - good first issues: Issues · rust-unofficial/patterns · GitHub

Lint duplicate dependencies and more with guppy - Create test to catch duplicate dependencies · Issue #1582 · ZcashFoundation/zebra · GitHub

Hi, I'm trying to reboot development on the Rust rewrite of Magic Wormhole. There are a lot of low-hanging fruits right now and I'll provide support with implementing them. Issues are tagged accordingly: Issues · magic-wormhole/magic-wormhole.rs · GitHub

If there's something I can do to become more contributor-friendly, let me know :slight_smile:

1 Like

[netstack3] Add reference counted HashMap

[netstack3] Verify behavior when attempting to forward IPv6 packets w/ forwarding disabled

[netstack3] Do not forward loopback addresses

[netstack3] Split IpProto into Ipv4Proto and Ipv6NextHeader

[netstack3] Send gratuitous ARP when a device is brought up

[netstack3] Figure out whether there's anything we need to do if we receive a malformed Ethernet frame

[netstack3] Figure out whether there's anything we need to do if we receive an unrecognized EtherType

[netstack3] Fuzz parsers and serializers

[netstack3] ARP: Add tests for ARP on a broadcast medium

[netstack3] Should we respond to inbound ICMP echo replies without sockets with a port unreachable error?

[netstack3] Make sure we properly handle unrecognized IPv6 next header values

[netstack3] Migrate all transport protocols to trait associated types

[netstack3] Implement InterfaceIndexToName and InterfaceNameToIndex

[netstack3] Deduplicate IGMP and MLD

Rust Berlin is searching for co-organisers with intent to mentor newcomers!

[netstack3] ARP: Add tests for ARP on a broadcast medium

[netstack3] Migrate all transport protocols to trait associated types

[netstack3] Split IpProto into Ipv4Proto and Ipv6NextHeader

[net-types] Add common prefix length calculation for IP addresses

[netstack3] Make sure ICMP messages are not sent in response to non-initial fragment packets

[internet-checksum] Clarify documentation around odd byte lengths

[netstack3] IP fragment reassembly vulnerable to FragmentSmack

[netstack3] Support stable interface IDs

[Starlight] Support for "unsafe" cases of finally