- User Since
- Sep 15 2015, 12:04 PM (217 w, 1 d)
^ Plays into https://github.com/ximion/appstream/issues/240
Mon, Nov 11
OEM configuration is driven by installers already e.g. calamares https://people.ubuntu.com/~apachelogger/screencasts/vokoscreen-2019-05-03_11-43-36.mkv or ubiquity https://userbase.kde.org/Neon/Installation/OEM#First_Boot
Both aforementioned use cases are addressed by the same software using the same code. The "steps" can be different though (e.g. OEM config mostly needs no partitioning so this step is not part of it).
Sat, Nov 9
Fri, Nov 8
fix tooltip scaling to show keys at 2.5 times their original size
install bin, drop ki18n as link target (not used at this time)
We have distro-independent ways to refer to software (appstream ids) so software stores understand what we mean. So, there is no technical problem here. Heck, even without it there wouldn't be. Calamares manages to be a distro-independent installer that can be used by all distros and made their own. There is no reason we couldn't have the same for a first start experience.
Oh oh oh, I forgot to actually read this.
Thu, Nov 7
I figure we want maximum exposure for this. So, much like we do with Plasma already I would suggest that we post the announcement on kde.org AND copy it to the dot.
Wed, Nov 6
D25170 for when that lands
NB: depends on https://gitlab.com/libssh/libssh-mirror/merge_requests/71 getting landed.
Tue, Nov 5
I think there's a smarter way of dealing with this somewhere in our finder, not blocking though. I'll take a look when I find a minute.
D25153 for reference.
Wed, Oct 30
TBH, I would move away from the hardcoding in general.... try to sendfile size_of_file and if n < size use n as new count for the next cycle. The second cycle will use the maximum regardless of what the specific kernel version has as maximum.
The maximum is an implementation detail of the kernel that may change every release, so hardcoding anything seems wrong here.
Tue, Oct 29
switch from list to bool since we don't actually use the list anyway
Mon, Oct 28
Fri, Oct 25
About the list of unexpected signals in forCommand():
Thu, Oct 24
Supposedly, I was being lazy though since there is no pre existing test and I don't exactly know if there's anything to watch out for when testing widgets (as in: I've never written a widget test before).
Hm, how about separate functions though? With a single stat any given build still needs N process forks even when they only want 1 value.
Wed, Oct 23
Not sure if that sort of application really needs to have regular commits ;)
Replaced by D24887 which instead creates a more generic system to verify slave behavior.
Tue, Oct 22
Mon, Oct 21
I've actually started work on a more general system for this. Will update soon.
Fri, Oct 18
works well enough it seems
When I put the code in a minimal standalone program I can confirm that the code works just fine. Are you sure your testing methodology is sound @ngraham ?
Thu, Oct 17
Wed, Oct 16
Tue, Oct 15
Oct 15 2019
Do we have a request for this outside kbibtex? My attitude towards adding things to ECM is always "is there more than one user".