Home GnuPG

Weekly Standup
ActivePublic

Hosted by wk on Aug 17 2020, 10:00 AM - 11:00 AM.

Recurring Event

Event Series
This event is an instance of E617: Weekly Standup, and repeats every week.

Details

Event Timeline

Last week:

  • I realized that I don't have a capability to support those who have been keeping their own peculiar way of using dev.gnupg.org; From a developer's view, before the analysis of a possible problem/bug itself, a developer would need to establish a good filtering methodology to the entangled view of the reporter. Perhaps, for them, this site is used just for writing something with less/no effort to better understandings to public.
    • I feel reading a bad BBS where a post to a thread is going to wrong thread (or no support of threads) and it is a reader who has to find out the relationship between them.
    • Focusing a bug report doesn't work to support them unfortunately
    • Instead, focusing a reporter would work better, but...
    • Perhaps, if we had helpdesk and/or customer relationship management division, it would be a task for them.
  • T5024: our old libtool would have some issues, but it works for our primary targets (GNU/Linux and Windows).
    • libtool upstream is also not that active
    • newer activities like slibtool seems no good support for macOS yet
    • conclusion: don't touch things around libtool for now
      • only minimum change for primary targets, if really needed

This week:

  • Learn the situation for macOS
  • bug fixes
  • Other work of mine: ship FST-01SZ to FSF

Last week:

  • Bug fixing
  • Add --chuid to all tools
  • Scute documentation update

This week:

  • Help with new card GUI
  • sysadm
  • bug fixing

Re: macOS: Patrick uses a different and it seems simpler script to build GnuPG; he will eventually stop to do that due to forthcoming chnaging in macOS. The question is whether we want to build an officaal gnupg.org version for macOS similar to what we do for Windows. In theory I like to do that to have better control over our bug reports. However, there is quite some overhead for us and we need to decide whether to spend the resources on this.

Last week:

  • Several demos and telkos with potential institutional users
  • Started refactoring GpgOLs attachment handling to avoid MAPI writes for T5022
    • Worked so far but the mapi to mime handling did not work properly. I might need an additional MAPI write after creating the OOM structures.
  • Made Compliance mode name configurable in Gpg4win through libkleopatrarc

This week:

  • Only mails and communication. Helping my wife to get her buissness started.