- User Since
- Mar 20 2019, 12:44 PM (30 w, 6 d)
@The_LoudSpeaker is all hot and bothered to get us some Pi images again since Ubuntu Pi Flavor Maker since Xenial. Perhaps in lieu of that, given that there are preinstalled server images for versions 2-4 (the latter is new) in Eoan, we recommend that people install lubuntu-desktop via those instead, like with this Xubuntu blog. @kc2bez and @Dreamingwolf also have 3's. Between the three of them, someone will check out how feasible/functional this is (we should really test it hard before making recommendations; all the hardware should be exercised heavily). I think I have a 2 that I could try it out on (I also should have a 3, but since there are others, I'm not sweating that). Anyone got a 4?
Sat, Oct 19
Thu, Oct 17
So? I'd rather people think they're stuck with a cute icon than the stupid thing.
Maybe we should set a default face icon in SDDM to the new Lenny????
Wed, Oct 16
For posterity's sake, the reason this is reverted is that it breaks the ISO building:
Tue, Oct 15
Mon, Oct 14
Fri, Sep 27
Wed, Sep 25
Tue, Sep 24
Mon, Sep 23
There is a limit on blob (read: MySQL) storage that is additionally limited by MySQL itself (see max_allowed_packet) but supposedly if we have another storage set up it should fall back to that and we have S3 set up to handle up to 8MB.
Just tried to upload it through arc myself and got the same error.
Fair enough, but testing one little file should be fairly easy. If the issue is actually on Dan's side, pushing directly probably won't work, either. At least at that point we know where to look.
Just to add some stuff I found:
- The "Failed to upload binary" error comes from the Arcanist code. This suggests it's not a git issue.
- There's no file size limit on rART.
- In the GUI, it shows a file size for each of the files.
- The raw diff seems to be invalid for the binaries. Compare to D45 or D20 which also has binaries.
- Changing the database limit (storage.mysql-engine.max-size) doesn't help.
- There is no other relevant limit that I can find in any of the settings for Phabricator in general.
- There's naturally HTTP and PHP upload limits but I'm not sure those are relevant. Default is 1MB for nginx and 2MB for PHP, though, FWIW.
Sep 20 2019
@guiverc thanks for that!!
Here's the patch that got us the Ubuntu logo in the xscreensaver lock dialog. It turns out this was reverted because gnome-screensaver would better integrate with the desktop.
Sep 19 2019
I just want to go on record as saying that I still want our shortcuts to primarily be defined in globalkeys. We should avoid as much as possible definitions elsewhere. Something is funky with runner, either in that it is conflict with globalkeys or that runner needs to be started before globalkeys. An upstream issue will be forthcoming (please post it here for posterity @The_LoudSpeaker) to try to get to the bottom of these issues. Once that's figured out, I'd like to get the definition back in here. Hopefully we can even get rid of the runner configuration that we have (that this depends on to work, AFAIK). Until then, we need to have something that works and this will get us there and much better than some weird dpkg-divert of the Desktop Entry or a restart script, etc. Great job in working hard on figuring this out!
Sep 18 2019
Sep 14 2019
Totally forgot about this!!! Can you send me an SVG @Guephren and I'll get this implemented? I do agree with @JyotiGomes (as much as I appreciate his sketch!) that yours is a little better. For one, the white/winter coat is historically more associated with the ermine. There's a heraldry pattern called ermine that is white not brown. Also, the tail is totally essential.
- default hacks
Sep 13 2019
Sep 9 2019
@kc2bez what do you think about using one of the stock ones versus making something ourselves?
Regarding the path, using apt-file search, it seems that the XScreenSaver* files are provided by xscreensaver packages, so those are out. These are overwritten in Ubuntu Studio and Xubuntu's default settings packages via providing .xscreensaver in /etc/skel. The problem with this is anyone upgrading will not have the changes. Maybe we could postinst the installation for old users? Any other ideas?
Sep 8 2019
Nice catch. To be fair, there's a lot of url and error variables thrown around that aren't the same and this makes the code really unreadable and unmaintainable. If you wanted to go ahead and fix that, using, e.g. httperror instead of error for the HTTPError exception, that would be an added plus.
Another idea (I'm full of them): we make our own hack for xscreensaver.
Maybe we should just pick one as the default rather than using random?
Sep 7 2019
So I should have said this before but I really don't like popsquares or slidescreen and fuzzy flakes is not a big favorite, either. Someone please overrule me, but I'd really like us to not include those. Since @tsimonq2 is the op here, maybe he can chime in?
- Please add the Last-Update field with today's date.
- You added the T117 reference in the commit message, but not in the differential revision. When you're ready to submit changes, just do arc diff --edit and change the summary section so that it includes "resolves T117."
- Picky (but potentially something that would render it non-compliant, depending on how smart validation tools are): add a space after the colon before the URI in Applied-Upstream.
- Your choice: If it were me, I'd probably get rid of lines 5-7 as they're not required parts of the diff at all.
You need to edit the patch to be DEP3 compliant, as seen in the packaging example. Also might want to edit the description to say it "resolves T117," which can be done, I think, via the --edit switch to arc diff.
Sep 6 2019
Sep 5 2019
Sep 4 2019
Aug 23 2019
Just to put this out there, the Debian packaging is super behind (Standards-Version 3.9.7, debhelper 9) so the maintainer hasn't really been maintaining it. There's a FTCBFS with a patch from 2017 that hasn't been touched. There's also been some discussion about using the new fork with some options mentioned.
Aug 22 2019
@tsimonq2 sez no need to SRU.
@tsimonq2 looks like waiting on upstream might take a long while. Maybe we should just implement this (as individual patches) and drop patches as needed as upstream makes developments?
So here's what we should probably have as required information for testing results:
- from lspci -nnk
- PCI ID of graphics card
- name of graphics card
- kernel module being used
- with ps -o rss -C compton | numfmt --header --field=1 --to=iec --padding=5, run under the same conditions and after the same amount of time elapsed since starting compton
- with old compton
- with new (PPA) compton
- The tests should be run under the following conditions
- with several windows open
- the same configuration, preferably with lots of opacity and transparency and shadows
- additional checks
- try youtube videos in full screen
- anything else graphic intensive: games, etc.