Need help building an AppImage for GNU Octave

Hi,
Before you ask me to request an AppImage upstream the answer is that this is a GNU Project, they only provide source code, no binary builds. Here is my present yaml:
app: Octave

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - octave/stable

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop

while it builds fine, the AppImage gives the error:
/bin/bash: ../lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/home/fusion809/.cache/thumbnails/normal/106ab48d0f68b0cd4e0df7cc56808f3d.png is missing. Probably not running ./bin//octave.wrapper from within an AppImage.
Hence falling back to using .DirIcon
octave: failed to exec '/usr/lib/x86_64-linux-gnu/octave/4.0.2/exec/x86_64-pc-linux-gnu/octave-gui'

usr/lib/x86_64-linux-gnu/octave/4.0.2/exec/x86_64-pc-linux-gnu/octave-gui does exist in the AppImage. The usr/bin/octave file is not a shell script, so I can't simply try tweaking it. It's a binary.
and fails to launch.
Thanks for your time,
Brenton

AppImage is a tool that empowers upstream application authors to ship binaries to end users without intermediaries. If the GNU project is not interested in this, then we won't get binaries directly from the GNU project and must live with whatever the distribution happens to ship. Personally I avoid anything coming from GNU for that very attitude, use the MIT license rather than LGPL, and try to move away from GNU tools if viable alternatives exist.
I really try to help any upstream project that wants to ship AppImages, but I don't offer the same level of support to work around uninterested projects like GNU that seem to have no interest in binary compatibility.

I just asked for help in the #octave IRC channel and suffice it to say they weren't really receptive. They don't do chat logging so I can't share that. Here's my copy-pasted log:

fusion809 Howdy folks. I was wondering if there's any interest among the developers of GNU Octave to provide a cross-distribution package for GNU Octave on Linux? I have made an attempt to build one myself but that failed (for details on how and why see this GitHub issue https://github.com/probonopd/AppImages/issues/120).
JordiGH fusion809: One distribution is work enough.
mtmx I have a very slight interest in playing with Flatpak at some point
fusion809 True and precisely why building one package that will work on all distributions is a good investment of time. Would save hundreds of hours working on packages for each individual distribution.
JordiGH I generally don't like the idea of being empowered to ship binaries without distributions.
JordiGH fusion809: It won't save the hours, it'll just accumulate them all in one point.
JordiGH I'm old and cranky and I think all ye kids thinking that debs and rpms are dumb are just unaware of the problems these things solve.
mtmx the problem with a cross-distro packaging project is that there are already at least 3 competing standards
JordiGH Or even better: someone comes up with a C++-specific package manager.
JordiGH Like every other language's language-specific package manager.
JordiGH Can't wait for cppget install octave
fusion809 Yes it would, as each distribution has a very different system for packaging.

JordiGH I mean, go ahead and do it, but I'll grump about it every step of the way.
JordiGH I'm sure others will love it.
fusion809 mtmx: yep there are three competing standards. So why not choose one that doesn't require root privileges in order to be run, like AppImages. Granted I'll be happy even if AppImages aren't used but rather flatpaks or snap packages are used.
JordiGH Also, these one-size-fits-all solutions are usually just a bit naïve about how many different sizes there are.
JordiGH one-size-fits-all doesn't even work for macOS, and there you're just targetting supposedly a single OS.
mtmx fusion809: it looks like your github issue was closed, so there's really nothing worth working on there, is there?
fusion809 It was closed because we couldn't go anywhere without help from the upstream developers. Hence why I'm here.
mtmx if you are asking for GNU Octave the project to build and maintain an AppImage binary, then no that is definitely not going to happen
mtmx if you are asking for help on a specific error or failure, we might be able to help
fusion809 OK, well does this channel have a log? If so I'd like to share it so I can document that I've at least given upstream a chance to help us.
mtmx no logging
JordiGH Just show them your own log.
JordiGH It's text.
JordiGH copy-paste it.
JordiGH fusion809: We already tried a one-size-fits-all thing. It's MXE. It's a lot of work and it doesn't quite work for everything.
mtmx Can you clarify what kind of help you are looking for?
JordiGH fusion809: Also, that probonopd person is quite obnoxious and thinks that we have some sort of ideological opposition to shipping binaries because of the GPL or something.
JordiGH It's not because of the GPL. It's because we tried it, doesn't work, and Octave is just way too complicated for a one-size-fits-all solution. Or at least that's my grumpy explanation. And now I want to argue with probonopod about how wrong they are in their opinions.

Not going to comment on everything, but on this one:

JordiGH: Also, that probonopd person is quite obnoxious and thinks that we have some sort of ideological opposition to shipping binaries because of the GPL or something.

I've never said that. It just looks to me like the primary concern of all things GNU is the openness of the code, whereas AppImage is designed for application authors who want to have end-to-end control over the end user experience without any intermediaries between the author and the user (aka "polished end-user experience"). It also happens that most GNU code is indeed picked up by most distributions, whereas applications in the "long tail" (think your local school's scheduling application) cannot be expected to show up in each Linux distribution.
So let's just say that the goals of the GNU project and the nature of GNU software as well of the GNU core audience and GNU developers don't align with the concerns of AppImage as much as, say, Qt cross-platform application developers or Electron-based cross-platform application developers which are much more end-user driven.

Don't worry JordiGH had a bite at me too later. Saying I dislike them because they love the GPL. Rofl, if you look at my original repositories (i.e., ones I haven't forked) you will see that at least 90% of them use the GPLv3 license.

While I try to use the MIT License wherever I can, I have nothing against the GPL. Just be aware that some companies will try to stay away from everything GPL if they can.
My point is that even if you care about the openness of the source, that doesn't have to mean that you don't care about a polished end-user experience or the availability of ready-to-use binaries...

True. The GNU Project, IMO, is still in the early 90s ideologically, thinking that Linux isn't to be user-friendly or polished, it's meant to be a user free-for-all, rofl. Or, alternatively, they think packagers should do all the polishing for them and package every new release for users, and by-and-large distro packagers tend to package once and forget about it until the next release of the distro (as is the case for Ubuntu it seems).

"GNU/Linux" that is ;-)

Ah btw I saw your GNU Octave Recipe (https://github.com/probonopd/AppImages/blob/master/recipes/octave/Recipe) and tried to build it but it failed. I have tried modifying it to get it to work and it's gotten stuck at line 22. Your AppImageKit doesn't contain a CMakeLists.txt file. Is it necessary for you to build appimagetool in the CentOS 6 container? Or was that written before you started to provide binaries for it? I'm asking because I want to know if I can simply switch those lines for a downloading the appimagetool binary you provide.

AppImageAssistant has been replaced by appimagetool. The recipe was written by @crayxt and I don't have much clue about it, sorry.

Guys, I'm still here. I can hear you.
We are not against usability nor about making Octave distributable because of GNU. In fact, several of us help with Octave packaging for Debian. I have done some of that, and so has Mike Miller. We are also not stuck in the 90s, since we have Octave a GUI after a lot of work. Because of this GUI, we are Qt cross-platform developers.
We are not opposed to what you're doing. It's just a lot of work and I'm very skeptical it can work better than what we're doing, but like It old @fusion809, I'm eager to be proven wrong.

Oh, one more thing. If you're able to create "universal" Octave binaries along with an easy recipe for reproducing them, I see no problem with including this recipe in our sources as well as distributing the binaries alongside these binaries for Windows:
http://alpha.gnu.org/gnu/octave/
My grumping is just skepticism, not a refusal.

Oh, one more thing. If you're able to create "universal" Octave binaries along with an easy recipe for reproducing them, I see no problem with including this recipe in our sources as well as distributing the binaries alongside these binaries for Windows:
http://alpha.gnu.org/gnu/octave/
My grumping is just skepticism, not a refusal.

@jordigh Ye art more polite 'ere than in the IRC. Didn't hear any eagerness at all in the IRC. But I'm glad you seem to have come around. I'm working in two veins to get an AppImage for GNU Octave available. Firstly I'm working on that RPM-based AppImage and I'm also trying to create Ubuntu 14.04 package for GNU Octave 4.2.0 so that I can then use that to build an AppImage.

Sorry, like I said, I probably was just hungry when I was grumping at you. (Not an excuse, just an explanation.) I did try to exhort you to prove me wrong.

Sorry, like I said, I probably was just hungry when I was grumping at you. (Not an excuse, just an explanation.) I did try to exhort you to prove me wrong.

@jordigh Well I got just got an error that maybe you can help me with. On a CentOS 6 Docker container I got the error:
configure: error: in `/Octave/octave-4.2.0':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details

config.log is here. Any ideas?

Rofl never mind, I figured it out. The Recipe I copied from this repo didn't install gcc-c++.

Now I'm getting:
  CC       sys_socket.lo
  CC       tempname.lo
  CC       glthread/threadlib.lo
  CC       glthread/tls.lo
  CC       tmpdir.lo
  CC       u64.lo
  CC       unistd.lo
  CC       dup-safer.lo
  CC       fd-safer.lo
  CC       pipe-safer.lo
  CC       wctype-h.lo
  CC       xmalloc.lo
  CC       xalloc-die.lo
  CC       xgetcwd.lo
  CC       xsize.lo
  CC       xstrndup.lo
  CC       asnprintf.lo
  CC       chdir-long.lo
  CC       fcntl.lo
  CC       fnmatch.lo
  CC       getcwd.lo
  CC       getcwd-lgpl.lo
  CC       getopt.lo
  CC       getopt1.lo
  CC       glob.lo
  CC       mbrtowc.lo
  CC       mktime.lo
  CC       nanosleep.lo
  CC       openat-proc.lo
  CC       printf-args.lo
  CC       printf-parse.lo
  CC       secure_getenv.lo
  CC       time_rz.lo
  CC       vasnprintf.lo
  CCLD     libgnu.la
make[4]: Leaving directory `/Octave/octave-4.2.0/libgnu'
make[3]: Leaving directory `/Octave/octave-4.2.0/libgnu'
make[2]: Leaving directory `/Octave/octave-4.2.0/libgnu'
preserving existing HG-ID file
make[2]: Entering directory `/Octave/octave-4.2.0'
  CXX      libinterp/dldfcn/libinterp_dldfcn___delaunayn___la-__delaunayn__.lo
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/cstdint:35,
                 from ./oct-conf-post.h:186,
                 from ./config.h:3485,
                 from libinterp/dldfcn/__delaunayn__.cc:42:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
In file included from ./liboctave/array/Array.h:37,
                 from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/dim-vector.h:205: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:207: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h: In constructor ‘dim_vector::dim_vector(octave_idx_type, octave_idx_type, Ints ...)’:
./liboctave/array/dim-vector.h:207: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:209: error: ‘initializer_list’ is not a member of ‘std’
./liboctave/array/dim-vector.h:209: error: expected primary-expression before ‘>’ token
./liboctave/array/dim-vector.h:209: error: ‘all_lengths’ was not declared in this scope
./liboctave/array/dim-vector.h:209: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x
./liboctave/array/dim-vector.h:210: error: expected initializer before ‘:’ token
./liboctave/array/dim-vector.h:213: error: expected primary-expression before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected ‘)’ before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected primary-expression before ‘}’ token
./liboctave/array/dim-vector.h:213: error: expected ‘;’ before ‘}’ token
In file included from ./liboctave/array/Array.h:38,
                 from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/idx-vector.h: At global scope:
./liboctave/array/idx-vector.h:68: error: ‘unique_ptr’ in namespace ‘std’ does not name a type
In file included from libinterp/corefcn/Cell.h:31,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/array/Array.h:282: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/Array.h:861: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/array/Array.h: In constructor ‘Array<T>::Array(const Container<T>&, const dim_vector&)’:
./liboctave/array/Array.h:876: error: expected initializer before ‘:’ token
./liboctave/array/Array.h:880: error: expected primary-expression before ‘}’ token
./liboctave/array/Array.h:880: error: expected ‘)’ before ‘}’ token
./liboctave/array/Array.h:880: error: expected primary-expression before ‘}’ token
./liboctave/array/Array.h:880: error: expected ‘;’ before ‘}’ token
In file included from libinterp/corefcn/Cell.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/util/str-vec.h: At global scope:
./liboctave/util/str-vec.h:59: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:59: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:130: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h:130: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./liboctave/util/str-vec.h: In constructor ‘string_vector::string_vector(const String_Container<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Other ...>&)’:
./liboctave/util/str-vec.h:138: error: expected initializer before ‘:’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘;’ before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘)’ before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected primary-expression before ‘}’ token
./liboctave/util/str-vec.h:140: error: expected ‘;’ before ‘}’ token
In file included from libinterp/corefcn/error.h:31,
                 from ./libinterp/octave-value/ov-base.h:40,
                 from ./libinterp/octave-value/ov.h:57,
                 from libinterp/corefcn/Cell.h:33,
                 from libinterp/dldfcn/__delaunayn__.cc:50:
./liboctave/util/unwind-prot.h: In member function ‘virtual void octave::unwind_protect::run_first()’:
./liboctave/util/unwind-prot.h:73: error: ‘unique_ptr’ is not a member of ‘std’
./liboctave/util/unwind-prot.h:73: error: expected primary-expression before ‘>’ token
./liboctave/util/unwind-prot.h:73: error: ‘ptr’ was not declared in this scope
In file included from ./libinterp/octave-value/ov-fcn.h:33,
                 from ./libinterp/octave-value/ov-builtin.h:30,
                 from libinterp/corefcn/defun-int.h:30,
                 from libinterp/corefcn/defun-dld.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:51:
./libinterp/octave-value/ovl.h: At global scope:
./libinterp/octave-value/ovl.h:57: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h:188: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h:190: warning: variadic templates only available with -std=c++0x or -std=gnu++0x
./libinterp/octave-value/ovl.h: In function ‘octave_value_list ovl(const OV_Args& ...)’:
./libinterp/octave-value/ovl.h:192: error: ‘initializer_list’ is not a member of ‘std’
./libinterp/octave-value/ovl.h:192: error: expected primary-expression before ‘(’ token
./libinterp/octave-value/ovl.h:192: error: ‘initializer_list’ is not a member of ‘std’
./libinterp/octave-value/ovl.h:192: error: expected primary-expression before ‘>’ token
./libinterp/octave-value/ovl.h:192: error: expected ‘;’ before ‘...’ token
In file included from liboctave/operators/mx-ext.h:54,
                 from ./liboctave/array/Matrix.h:34,
                 from ./liboctave/util/lo-regexp.h:34,
                 from libinterp/corefcn/symtab.h:36,
                 from ./libinterp/octave-value/ov-fcn.h:36,
                 from ./libinterp/octave-value/ov-builtin.h:30,
                 from libinterp/corefcn/defun-int.h:30,
                 from libinterp/corefcn/defun-dld.h:32,
                 from libinterp/dldfcn/__delaunayn__.cc:51:
liboctave/numeric/svd.h: At global scope:
liboctave/numeric/svd.h:43: warning: scoped enums only available with -std=c++0x or -std=gnu++0x
liboctave/numeric/svd.h:50: warning: scoped enums only available with -std=c++0x or -std=gnu++0x
liboctave/numeric/svd.h:60: error: ‘octave::math::svd::Type’ is not a class or namespace
liboctave/numeric/svd.h:61: error: ‘octave::math::svd::Driver’ is not a class or namespace
libinterp/dldfcn/__delaunayn__.cc: In function ‘octave_value_list F__delaunayn__(const octave_value_list&, int)’:
libinterp/dldfcn/__delaunayn__.cc:197: warning: use of old-style cast
make[2]: *** [libinterp/dldfcn/libinterp_dldfcn___delaunayn___la-__delaunayn__.lo] Error 1
make[2]: Leaving directory `/Octave/octave-4.2.0'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Octave/octave-4.2.0'
make: *** [all] Error 2

@fusion809 it could be that compiler is too old, check with epel-7 chroot.

My Debian package attempt at building an AppImage has gone further than my attempt at using CentOS. I have an AppImage but whenever I run it I get the error:
/bin/bash: /tmp/.mount_d5Q1Q7/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_d5Q1Q7/usr/lib/libgl2ps.so.0: no version information available (required by
 /usr/lib/x86_64-linux-gnu/octave/4.2.0/liboctinterp.so.4)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_d5Q1Q7/usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found
(required by /usr/lib/libGraphicsMagick-Q16.so.3)

any ideas @probonopd or anyone else? Here is my yaml:
app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - brentonhorne/octave

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - cp ./usr/share/octave/4.*/imagelib/octave-logo.svg octave.svg

Looks like usr/lib/x86_64-linux-gnu/libgomp.so.1 needs to be at least version GOMP_4.0. Does it work using the same ppas without the AppImage?

What do you mean does the GNU Octave package in the brentonhorne/octave Trusty repository work? If so yes I have tested it in a Docker container for Trusty and it works fine.

Honestly I don't know. I am not an expert in GNU Octave, in libgomp, nor in compiling stuff in general, sorry. This kind of thing is best handled by the people who wrote the software and are knowledgeable about it, imho.

If they would do this stuff themselves I wouldn't be bothering creating an AppImage myself.

Right ;-)

If they would do this stuff themselves I wouldn't be bothering creating an AppImage myself.

Well, now you see why we don't do it ourselves: this is a lot of work, and most of our users using GNU-based distributions are already able to install Octave from their repos. I am glad to see you working on it yourself, though.
I have worked on the Debian package in the past. I know how to build Octave using the Debian repos to fetch the dependencies, but libgomp is a new one to me. Oh, it's for OpenMP, which is kind of part of gcc. It's very strange you're getting a version mismatch. Are you mixing gcc versions?
Are you already following the build instructions for Debian?
I don't know yet how AppImages work. I was hoping you could easily translate a deb or rpm into this new packaging format. What does your yaml recipe do? Obviously it doesn't just grab the Ubuntu source package and build it in the version of Ubuntu that it's known to work in, because, well: that would have worked. Or are you trying to update the Debian packaging for that PPA?
It appears you grabbed some unknown bloke's PPA. Try this one instead,
maintained by our own Mike Miller (mtmx in IRC), who also works on the Debian packaging. I expect the 4.2 release from Thursday will be there soon.

I don't know yet how AppImages work. I was hoping you could easily translate a deb or rpm into this new packaging format. What does your yaml recipe do?

Normally a .yml should do exactly what you describe: grab debs from a repository/ppa and convert them into an AppImage. Now, in this case the brentonhorne/octave ppa is used which is made by @fusion809 himself...

Yeah brentonhorne/octave is my PPA. I forked it from mtmx's as his was out-of-date. Using his packages gives the error I opened this issue with. See this packages don't seem to provide the GUI of GNU Octave, just its CLI. No we're not mixing GCC versions, just using that provided by Trusty in the build of the original Debian package in my repo. That Debian package works fine in a Trusty Docker image so I doubt it's a straightforward issue with the packages themselves.

Hm, it's out of date by two days. 4.2 was just released on Thursday. There's a Debian packaging in experimental for the 4.1.0 unreleased development version, which probably can be adapted for Ubuntu. I expect Mike will update the official PPA soon, after 4.2 lands in Debian.
Is there a way to get a more informative error message from the original message? Why did it fail to execute?The 4.0 official PPA does provide the GUI.

4.2 has been out since the 14th of November, or at least its source code has been https://ftp.gnu.org/gnu/octave/. As for getting a more verbose error message I'm not sure, @probonopd any ideas?

So, the octave wrapper is a shim binary that should fork+exec into octave-gui or octave-cli. So I assume the fork worked but the exec didn't.
Can you execute octave-gui directly?

Running octave from within the AppDir works fine and confirms that 4.2 was released on 14 November 2016.

Does seem odd that it runs fine, but when I uninstall GNU Octave from my system on which I'm testing it does give an error. It seems to me like the octave and octave-cli binaries are not portable and maybe that's somehow causing this error. Especially my original error that I opened this issue with, the one from the octave/stable PPA. AppImages work best when the binaries they're made from are portable, I do believe. Which is why where possible we build them from binary tarballs instead of Debian packages.

What's an AppDir directory? What were you running it under before where it didn't work?
What does "portable" mean in this case? Does it mean it should statically link all dependencies? What's the difference between a binary tarball and a Debian package?

AppDir is what we make AppImages from. See AppImages are disk images (built with SquashFS) made by compressing AppDirs. Portable in this context means that it doesn't call on a absolute file location (like /usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui) in one's file system, it calls on a relative location (e.g., the octave binary might call on the relative location ../lib/x86_64-linux-gnu/octave/4.2.0/x86_64-pc-linux-gnu/octave-gui). Binary tarballs are archives which contain all the files required to run the program and when they are extracted (like any tarball) an executable binary file inside can be run (e.g., one called octave for a GNU Octave tarball). The beauty of binary tarballs is that you can move them anywhere in your file system, extract them and run them without a problem. This property of them also makes them fit the definition of "portable".
Debian packages, on the other hand, contain files that are designed to be placed in very specific places in your local file system when they're installed (e.g., for an GNU Octave package the octave binary is meant to be placed in /usr/bin the octave-gui file is meant to be placed in /usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/). Many of them depend on these very specific locations in order for them to be properly run (as they call on absolute paths instead of relative paths). This is what makes their contents not portable.
I hope I explained this clearly.

Oh, I see, you guys are recreating macOS app bundles for GNU-based distros.
So, binary tarballs require you to bundle all of the dependencies, correct? They don't have to statically link them, but they have to ship them. For this purpose, it might be far easier to try to go with MXE than Debian packages. MXE will download and compile most of Octave's dependencies. It stops at system things like X and glibc, though.
It will require deep surgery into Octave's build system to make all of those paths relative. They are all defined at configure time.

Yes, AppImage is kinda like an Apple .app inside a .dmg.
For relocateability, there are solutions like binreloc and I wonder why not more projects are using them.
Isn't MXE Windows-only? We don't want or need to bundle system things like X and glibc.

@probonopd Na MXE is not Windows only, the MXE article at the Octave Wiki has Linux-only instructions even. I'm trying a build to see if I can adapt MXE into an AppImage.

Wow, that'd be awesome.
This is working for me, gives 4.0.2:
app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - octave/stable

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - mv ./usr/lib/x86_64-linux-gnu/octave/*/*.so* ./usr/lib/x86_64-linux-gnu/
  - ( cd ./usr/lib/x86_64-linux-gnu/octave/*/ ; ln -s ../../exec/ . )
  - mv ./usr/lib/lapack/*.so* ./usr/lib/ # Why don't they put it there?
  - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Why don't they put it there?
  - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # What stupidity is this?
  - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # What stupidity is this?

Nice, as for MXE its build failed on Ubuntu 16.04 with error:
[download] gnutls
[build]    gnutls

Failed to build package gnutls!
------------------------------------------------------------
  ***
  *** Libnettle 2.7.1 was not found. Note that this version of gnutls doesn't support nettle 3.0.
/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/Makefile:801: recipe for target 'build-only-gnutls' failed
make[2]: *** [build-only-gnutls] Error 1
make[2]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
real    0m22.494s
user    0m17.800s
sys     0m0.624s
------------------------------------------------------------
[log]      /home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/log/gnutls

Makefile:801: recipe for target '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/gnutls' failed
make[1]: *** [/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/gnutls] Error 1
make[1]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
Makefile:523: recipe for target 'all' failed
make: *** [all] Error 2

For me your yaml fails with error:
+ bash -ex /tmp/recipe_script
+ sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
+ mv www.octave.org-octave.desktop octave.desktop
+ mv ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.so ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.so.1 ./usr/lib/x86_64-linux-gnu/octave/4.0.2/liboctgui.
so.1.1.0 ./usr/lib/x86_64-linux-gnu/
+ cd ./usr/lib/x86_64-linux-gnu/octave/4.0.2/ ./usr/lib/x86_64-linux-gnu/octave/api-v50+/ ./usr/lib/x86_64-linux-gnu/octave/packages/ ./usr/lib/x86_64-linux-gnu/oc
tave/site/
+ ln -s ../../exec/ .
ln: failed to create symbolic link './exec': File exists

Love teh gnu* ;-)
Btw, using your ppa the following seems to work:
app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - brentonhorne/octave

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - mv ./usr/lib/x86_64-linux-gnu/octave/*/*.so* ./usr/lib/x86_64-linux-gnu/
  - mv ./usr/lib/lapack/*.so* ./usr/lib/ # Why don't they put it there?
  - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Why don't they put it there?
  - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # What stupidity is this?
  - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # What stupidity is this?
  - cp ./usr/share/octave/4.2.0/imagelib/octave-logo.svg octave.svg

But do you promise to keep your ppa up to date, so that on each GNU Octave release date you will have the latest in your ppa? See, another reaon why I'd prefer upstream to do it....

- mv ./usr/lib/lapack/*.so* ./usr/lib/ # Why don't they put it there?
- mv ./usr/lib/libblas/*.so* ./usr/lib/ # Why don't they put it there?
- ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # What stupidity is this?
- ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # What stupidity is this?

Can we keep the snide remarks to a minimum? I'm honestly trying to understand you guys. If we both think the other side is just a bunch of incompetent idiots, we're not going to get anywhere.
To answer your questions, LAPACK underwent a transition from gcc to gfortran, which is what "gf" stands for. The gf suffix was dropped long ago, but some things might still want it. Additionally, there are several atlernative implementations of LAPACK and BLAS, such as ATLAS, MKL, or OpenBLAS. These are fundamental, old, and very reliable linear algebra libraries used by all scientific computing packages. The reason the libraries are above /usr/lib is to allow alternative versions and implementation concurrently and to allow Octave (or any other scientific computing package) to dynamically switch implementation at dynamic link time.

Love teh gnu* ;-)

Please stop.

Well I've always had a love of Octave:
app: Octave
union: true

ingredients:
  package: octave
  dist:    trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  ppas:
    - brentonhorne/octave

script:
  - sed -i -e 's|/usr/bin/||g' www.octave.org-octave.desktop
  - mv www.octave.org-octave.desktop octave.desktop
  - mv ./usr/lib/x86_64-linux-gnu/octave/*/*.so* ./usr/lib/x86_64-linux-gnu/
  - mv ./usr/lib/lapack/*.so* ./usr/lib/ # Why don't they put it there?
  - mv ./usr/lib/libblas/*.so* ./usr/lib/ # Why don't they put it there?
  - ( cd usr/lib/ ; ln -s libblas.so.3 libblas.so.3gf ) # What stupidity is this?
  - ( cd usr/lib/ ; ln -s liblapack.so.3 liblapack.so.3gf ) # What stupidity is this?
  - cp ./usr/share/octave/4.2.0/imagelib/octave-logo.svg octave.svg

@jordigh sorry if the comments offended you. It's just that I have never seen any library need suffixes like "gf" appended to a .so name and it's hard as an "outsider" to understand the purpose of those. Stuff like this can drive the occasional user nuts. Anyhow, thanks for your explanation. Will edit the comments.

*** Libnettle 2.7.1 was not found. Note that this version of gnutls doesn't support nettle 3.0.

Hm, this is strange. Nettle should be built by MXE-Octave too. I wonder if somehow gnutls is finding your system nettle instead of the one that MXE built. Do you see nettle 2.7.1 getting built before gnutls?

Well nettle is listed as one package built built:
[download] nettle
[build]    nettle
[done]     nettle

Is there a way to mask my system installation of nettle from it? Uninstalling nettle will uninstall a few pieces of software I'd rather not go without.

@probonopd your yaml for my repo fails for me. It builds fine but when run it gives the same error as I got:
/bin/bash: /tmp/.mount_1QSzpI/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_1QSzpI/usr/lib/libgl2ps.so.0: no version information available (required by
 /usr/lib/x86_64-linux-gnu/octave/4.2.0/liboctinterp.so.4)
/usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: /tmp/.mount_1QSzpI/usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found
(required by /usr/lib/libGraphicsMagick-Q16.so.3)

Now that's interesting... because it runs for me and I don't have any local GNU Octave installed. But I do have local ImageMagick installed, maybe this is making a difference? Just guessing here.

@fusion809 is there a way in MXE to specify a specific (old) glibc?

I was one step ahead, rofl, I uninstalled GNU Octave before testing the AppImage. I have ImageMagick installed locally. As for specifying an old glibc I haven't the foggiest. I don't much about MXE at all, just what that Octave Wiki article says and what I've heard in the #octave IRC channel.

Oops, on Fedora-Workstation-Live-x86_64-24-1.2.iso I get /usr/lib/x86_64-linux-gnu/octave/4.2.0/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory.  On ubuntu-14.04.1-desktop-amd64.iso it runs cleanly though.

On openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso I get:

p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory

On my Ubuntu 16.10 VM it runs fine. Fedora 24 gives me the same error as you got.

@fusion809 See my edit above, it works for me now.

Does your new YAML work for you on Fedora 24? For me it doesn't. Maybe adding libcurl3-gnutls to the packages: field will work?

As I wrote above:

EDIT: Added that library, now runs on Fedora 24 too. (Delete any pre-existing Octave folder you might have from previous runs and re-run the recipe, then it gets the updated excludedeblist.)

With your update it does run for me on Fedora 24 but it gives the error you got on openSUSE Tumbleweed.

Do you notice any ill effects or is it just cosmetic?

Seems to be just cosmetic.

@probonopd Btw whenever I use the trigger script I get the error message:
Create a temporary GitHub authorization
{ "message": "Validation Failed", "errors": [ { "resource": "OauthAccess", "code": "already_exists", "field": "description" } ], "documentation_url": "https://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization" }
Get a travis token using the GitHub token
not a Travis user
not a Travis user
/proc/self/fd/11: line 86: [: too many arguments
Trigger a build

and I haven't the foggiest why. Do you have an idea? My trigger.sh script is the same as yours except with my username substituted.

Your authorization on GitHub already exists (was not deleted after a previous run). You need to log into the GitHub settings -> Personal access tokens and delete the extraneous one.

You're right, thanks. I re-installed Ubuntu 16.04 though, as I thought I had something wrong with my procfs. It fixed some issues with my system, so it wasn't a total waste of time. I'm mentioning this because I tried running this GNU Octave AppImage again and I got the same error as before.

The error of the trigger script has nothing to do with your local machine.

@jordigh I haven't given up on MXE. I uninstalled nettle and I have gotten up to step 10 in the Linux section of the MXE article at the GNU Octave Wiki http://wiki.octave.org/MXE. The problem is that libblas.so and libopenblas.so do not exist in usr/lib. I have run make openblas and it ran without any errors reported.

If it helps when I run find . -name "*blas*" from the usr directory I get the output:
./i686-w64-mingw32/lib/libblas.dll.a
./i686-w64-mingw32/lib/cmake/openblas
./i686-w64-mingw32/lib/libopenblasp-r0.2.18.a
./i686-w64-mingw32/lib/libopenblas.a
./i686-w64-mingw32/lib/libopenblas.dll.a
./i686-w64-mingw32/include/suitesparse/cholmod_blas.h
./i686-w64-mingw32/include/f77blas.h
./i686-w64-mingw32/include/openblas_config.h
./i686-w64-mingw32/include/octave-4.2.0/octave/lo-blas-proto.h
./i686-w64-mingw32/bin/libopenblas.dll
./i686-w64-mingw32/bin/libblas.dll

@jordigh Yeah I got this error when using MXE to build GNU Octave:
[build]    freetype
[done]     freetype
[build]    fltk
[done]     fltk
[build]    xz
[done]     xz
[build]    tiff
[done]     tiff
[build]    lcms
[done]     lcms
[build]    ghostscript

Failed to build package ghostscript!
------------------------------------------------------------
base/unixlink.mak:54: recipe for target 'bin/gs' failed
make[3]: *** [bin/gs] Error 1
make[3]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/tmp-ghostscript/ghostscript-9.16'
/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/Makefile:801: recipe for target 'build-only-ghostscript' failed
make[2]: *** [build-only-ghostscript] Error 2
make[2]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
real    3m35.806s
user    3m3.696s
sys     0m10.704s
------------------------------------------------------------
[log]      /home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/log/ghostscript

Makefile:801: recipe for target '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/ghostscript' failed
make[1]: *** [/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2/installed-packages/ghostscript] Error 1
make[1]: Leaving directory '/home/fusion809/Programs/MXE-Octave/mxe-octave-64063cd35eb2'
Makefile:523: recipe for target 'all' failed
make: *** [all] Error 2

it ran fine up 'til then. Yes I have installed all the dependencies listed at mxe.cc/#requirements.


Allow LocalDate as path parameter

It is currently possible to use UUID as a path parameter for example and this works fine. However, if you pass a LocalDate object, it does not work.
get("/api/reservations/{date}", LocalDate.now())

The reason seems to be that the LocalDate is serialized to "2024-04-10" and then URL encoded to %222024-04-10%22.
I believe that updating SerializationSupport#isSerializableCandidate() to include LocalDate.class could fix it as it would use the toString() of LocalDate instead of letting a JSON serializer serialize the object.
As a workaround, you can currently manually call the toString() on the LocalDate object:
get("/api/reservations/{date}", LocalDate.now().toString())

maybe fixed at #1756


Gitops refactor

Created a new folder that contains the Gitops refactor for bootstrapping SRE apps on a new cluster based on Gitops principle with Argocd + Vault + kustomization.
Currently contains basic components: Argocd, ACM, Observability(with custom alerts, dashboard and metrics), Prometheus config and Alert manager config(SLACK, Pager Duty) and Grafana-dev. Need to remove exist duplicated manifest later.

/lgtm

Some enhancement need to handle later:

Add the installation log file to keep the install log
For preset Vault secret, instead of manual operation, better to make a script that could read manifest contains secrets definition then call Vault api to put all secrets into Vault automatically.


Question related to Remote debugging and version of Python

Do I need to have the same version of Python on my local (Windows 10) machine and on the remote machine(Debian 9.4) for remote debugging through Visual Studio Community 2019? Currently, my local machine has CPython 3.7.5 (64-bit) and the remote machine has CPython 3.5.3 (64-bit) and I'm getting "Failed to launch debug adapter!" error when trying to remotely debug a 'Hello World' sort of Python program. The inner exception is "InvalidOperationException: Path to debug adapter executable not specified." I tried a few things and the next one I would like to try is to have both the OS with the same version of CPython installed. I thought to have a quick check over here before submitting a detailed issue.

Can you try a remote debugging on localhost to see if that works better?
Also, make sure to install the same version of debugpy into the Python environment as the one that is bundled with PTVS (to see the bundled version, run import debugpy;print(debugpy.__version__) with F5).
There were further changes to launch/attach in VS 2019 16.6, so if you are on 16.5, it would be worth upgrading.
For example, for me I run this with CTRL+F5 then attach to tcp://localhost:5678 and it stops at the breakpoint. FYI I am on unreleased build of VS where we bundle 1.0.0b10, yours will likely have an older version bundled.

Can you try a remote debugging on localhost to see if that works better?

I already did and that works. I'm able to attach to process on 'localhost'

Also, make sure to install the same version of debugpy into the Python environment as the one that is bundled with PTVS

This info is helpful. I figured out how to get the bundled version number. The bundled files reside at "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\Microsoft\Python\Core" on my machine. The bundled version for me is 1.0.0b5. The version that gets installed using pip resides at "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\Lib\site-packages". I thought I could just replace the debugpy folders at both the locations with the newer version (1.0.0b11) and would make it work. Thank you for letting me know that's not going to work. Will make sure to use the bundled version going forward.
Anyways, looks like my problem is with the firewall settings. When I do a Telnet on 'localhost' (while my program with debugpy statements is running), I do get the following JSON response

But when I telnet to my localhost using it's IP, the connection times out. And the same behavior is seen for the remote server. Even when I try to attach to my local process by giving my local IP, I get the same error as mentioned in the starting of this thread. That makes me believe there's firewall problem.
I'm troubleshooting for that and would update once I have a firm answer.

I figured out what the problem was. My firewall settings were fine, it's just that the remote machine has two versions of Python and I installed debugpy only for the one I was running my program against. I have filed a separate bug for this issue. Closing this one. Here's the link for the bug - https://github.com/microsoft/debugpy/issues/316
Thanks for all the answers and support!


I want to check on startup if the SVT in the UDC are high enough to monitor my transfers

Description
As Chris, I want to check on startup if the SVT in the UDC is high enough to monitor my transfers so that I don't run into a risk of losing tokens.
Acceptance criteria

If the SVT in the UDC is not high enough I cannot continue using the dApp until I have minted and deposited more SVT in the UDC.

Monitoring Reward

raiden.config.monitoringReward: BigNumber | null = null
raiden.updateConfig({ monitoringReward: parseUnits('5', 18) })

Tasks

[ ]

@andrevmatos I was thinking about implementing this in the SDK. I would like to avoid people using the SDK withouth the monitoring service.

Not sure, I think we can't implement it in the SDK. There're usecases where MS can't be enforced, like always-online cli instances,  and on those, there's actually no way to notify the user about it (there's no UI, at most some log.warn spamming), and shutting down the SDK is even worse, as it shuts down the other, unrelated functionality (like sending) and could give bigger problems.
OTOH, we do can implement notifying mechanisms, and then the client's implementation (if possible, e.g. dApp) can react on it by showing notifications or even triggering SDK's shutdown.
Additionally, we could have a config value to enable receiving only if MS is operational (i.e. UDC deposit and params set); this way, incoming transfers would be rejected (as they're today) and the UI is then responsible for bothering the user about depositing if it wants to receive them.

@andrevmatos Thanks for your answer :)
We need to ensure, that the SDK is not getting used without receiving transfers getting monitored.
If I understand your comment correctly we would go with:

Additionally, we could have a config value to enable receiving only if MS is operational (i.e. UDC deposit and params set); this way, incoming transfers would be rejected (as they're today) and the UI is then responsible for bothering the user about depositing if it wants to receive them.

In addition, we would need to check if the deposit is high enough.

Please assign the "Ready" label after the design has been done, thanks :)

Sure thing!

This would fix #1489 as well.

@christianbrb @andrevmatos @nephix @kelsos

This is done in #1494
https://github.com/raiden-network/light-client/pull/1494/files#diff-dcc43c7ef66fb249deff95ea1ee84c4bR90
This enables receiving by default only if monitoringReward >= udcBalance.
We can look into exposing it to the dApp if wanting to notify the user the receiving is enabled or disabled.

@taleldayekh Looks nice
I would move this snippet to #1489 and keep the left screen in this issue to keep the discussions focused

Do we need a new screen for this? Checking the MintDepositDialog it seems that it is self-contained so we could reuse that instead.

I think it needs to be accessible at any time since the UDC token balance is critical. The user should be able to top it up whenever. I don't think it would be a nice solution to have that dialog appear all over the place.

Mockup:
https://xd.adobe.com/view/247b287e-eb36-4445-7fb4-024fdaa71e71-524a/


Further prioritize current version in README

I further prioritized the current version instructions in the README by removing the "v2" with "current version" and moving the v1 stuff to the back.

Thank you, @piotrowski !


Add time spent mapping to export .csv

It would be helpful for Project Managers to know how much time is spent mapping per task.  This can help with both planning how long a challenge/project may take, and also identifying trends within a challenge/project.

Thanks for the feedback, @nathanopen! A new CompletionTime CSV column is included in the v3.5.7 release, which was tagged yesterday and will be deployed to maproulette.org on Monday. However, it will only have data for tasks completed going forward (post-deployment).

This is now available on maproulette.org


Removing GKE from OnTag. Add rules for 2.5 v. 2.6.

Issue:
https://github.com/rancher/qa-tasks/issues/429 tackling in 2 sets (one in fixes, another in adding rke2)
Problem

ontag was broken.
Solution

We are removing GKE for now. Some other fixes include a check in the jenkinsfile for 2.5 or 2.6, and setting versions to run based on the rancher version. This will allow the user to set RKE_VERSION and RANCHER_K3S_VERSION, as well as has some defaults set in jenkinsfile for 2.5 and 2.6.
Testing
Tested in jenkins, will send runs separately.

after offline discussion, removed lines regarding eks/aks testing on 2.6.0-2.6.3.


wayland: Reset the interrupted flag before breaking from run_forever

This is important for any code that re-enters run_forever after some previous interrupt.
cc @vberger
Edit: The CI error seems to be an unrelated appveyor windows bug.

LGTM, looks like I forgot this when I implemented all this.


"Move Up" button does not work with last command

This button should bring the command up, but with the last element it simply does not work.

Just discovered this app, ran into same issue. As workaround move the item above the bottom item down. Once its no longer the bottom most item the intended item moves as normal.
Its not a fix, but you wont have to delete a configured item attempting to arrange them how youd like.

Just discovered this app, ran into same issue. As workaround move the item above the bottom item down. Once its no longer the bottom most item the intended item moves as normal.
Its not a fix, but you wont have to delete a configured item attempting to arrange them how youd like.

Yes, he did. But still it's quite annoying.


[release/1.4 backport] snapshot/devmapper: log exported methods correctly

backport of https://github.com/containerd/containerd/pull/5655

View was somehow logging itself as "prepare"
Cleanup should have its debug log as like other exported methods

@kzys @AkihiroSuda PTAL
@AkihiroSuda I saw you marked this for backporting; a bit unsure if this was needed for 1.4 as well (seems rather minimal, although overall looks "safe")


Added more fields in models from upload view

hi ,
i am using django-jfu
all working well,
but now i want to pass one more field from upload view
my model for image is product_image fields are
product = models.ForeignKey('Product', verbose_name=_('Product'), null=True, blank=True)
file = models.FileField( upload_to = settings.MEDIA_ROOT ,null=True, blank=True)
file are saved from upload view but i want to save 'product ' also for his relation ship so how can i do that
i am added jfu form in product add form template
please help me for solve this issue,
Thanks in Advance!!!

From Add Product Template, try to pass the product_id in the URL
Template
{% jfu 'file_uploads.html' 'jfu_upload' product_id %}

urls.py
***
    url(r'upload/(?P<product_id>[0-9A-Za-z-]+)', views.upload, name='jfu_upload'),
***

views.py
@require_POST
def upload(request, product_id):
    file_data = upload_receive(request)
    instance = Model(file=file_data, product_id=product_id)
    instance.save()

    basename = os.path.basename(instance.file.name)

    file_dict = {
        'name': basename,
        'size': file_data.size,
        'url': settings.settings.MEDIA_URL + basename,
        'thumbnailUrl': settings.MEDIA_URL + basename,
        'deleteUrl': reverse('jfu_delete', kwargs={'pk': attachment.pk}),
        'deleteType': 'POST',
    }

    return UploadResponse(request, file_dict)

Did you solve your issue ?
I'm trying this the "Setting formData on upload start for each individual file upload" on : https://github.com/blueimp/jQuery-File-Upload/wiki/How-to-submit-additional-form-data#adding-input-fields-to-the-upload-form
i add some html input within the template, and for js :
$('#fileupload').bind('fileuploadsubmit', function (e, data) {
var inputs = data.context.find(':input')
data.formData = inputs.serializeArray();
console.log(data);
The console log in Firebug give me the value in "formData", but i don't know how to get this value in Django/python.


Use Event Page instead Background Page

This extension is required just in page load, event page should be used.
https://developer.chrome.com/extensions/event_pages

Hi @ArthurAssuncao,
Thank you, I will look when I have a moment!
Bests

Version 0.3.1 just released, thanks for your contribution!
Bests


fix: drawing-tablet stylus touch events being prevented

On touchstart we were preventing the default for non-android devices, which prevented focus on drawing-tablet devices (Wacom) when touching canvas with stylus in pen mode.
This PR now prevents the default only on iOS devices.
Needs testing on Android tablets. /cc @zsviczian

Gonna merge. Tested on iPadOS, iOS, Android, Wacom. Don't have access to Android tablets, so if something breaks there, we can keep preventing the default on Android.


[AVOCADO-226] Upgrade to ADAM 0.22.0

Resolves #226.

Coverage remained the same at 84.055% when pulling 72d409c7e924df30b1ddcc8cc2cac641491526f8 on fnothaft:issues/226-adam-0.22.0 into 6bfa3564329bbd96bf1b74deaa7a7d9edbb30547 on bigdatagenomics:master.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/avocado-prb/178/
Test PASSed.


Updated configs for Seven days to die v1.0 (draft)

Updated configs to support v1.0.
For some reason however, the seven-days-to-diesettingsv100.xml is always empty after the initial download of the files.
No idea where that comes from. When I put my config content into the file manually however, everything works like a charm!

That's likely because you have the UpdateSource set to the CubeCoders repo. So it fails. If you set it to yours temporarily it will likely work.

That's likely because you have the UpdateSource set to the CubeCoders repo. So it fails. If you set it to yours temporarily it will likely work.

That was it. Thanks. Now everything works. The Server starts up without any errors but I still can't connect to it....
But I'm assuming thats a networking problem on my side.

@IceOfWraith So I am trying around with the port forwarding and what I don't get is that the ports configured in the configv100.xml and the ...ports.json are different than the ones which show up in the AMP Web Interface. It should be port 26900, but in AMP it's 27015. Where is that mapping coming from and where can I configure it? I assume the problem is, that the ports in the Port range 27000+ are being used by Steam and that creates some problems?

Coz those ports are not in your default application port ranges in amp. Change it to "all except excluded"

Coz those ports are not in your default application port ranges in amp. Change it to "all except excluded"

Gotcha! Now the "correct" ports are used. I still get "Could not retrieve Server information" when I try to connect...
I'm testing on the local Network. Any idea how to troubleshoot this further?

Okay now it's working! It was the port forwarding in my docker configuration (I use AMP dockerized).
I'll create a new final pull request.

I use AMP dockerized
Now you know that is not a supported setup


Add protocols for enzymatic degradation of vitrimer generated microgels

Summary
An end-to-end simulation pipeline for generating and reacting realistic microgels generated by vitrimer-driven patchy particle simulations.
Issues

[x] #39

closed #41


Vulnerability roundup 104: imagemagick-6.9.12-19: 16 advisories [9.8]

search, files

[x] CVE-2016-5841 CVSSv3=9.8 (nixos-21.05)
[x] CVE-2018-16328 CVSSv3=9.8 (nixos-21.05)
[x] CVE-2018-16329 CVSSv3=9.8 (nixos-21.05)
[x] CVE-2019-17547 CVSSv3=8.8 (nixos-21.05)
[x] CVE-2019-13136 CVSSv3=7.8 (nixos-21.05)
[x] CVE-2021-20310 CVSSv3=7.5 (nixos-21.05)
[x] CVE-2021-20311 CVSSv3=7.5 (nixos-21.05)
[x] CVE-2021-20312 CVSSv3=7.5 (nixos-21.05)
[x] CVE-2021-20313 CVSSv3=7.5 (nixos-21.05)
[x] CVE-2017-11447 CVSSv3=6.5 (nixos-21.05)
[x] CVE-2020-25663 CVSSv3=5.5 (nixos-21.05)
[x] CVE-2020-27829 CVSSv3=5.5 (nixos-21.05)
[x] CVE-2021-20243 CVSSv3=5.5 (nixos-21.05)
[x] CVE-2021-20244 CVSSv3=5.5 (nixos-21.05)
[x] CVE-2020-27768 CVSSv3=3.3 (nixos-21.05)
[x] CVE-2020-27769 CVSSv3=3.3 (nixos-21.05)

CVE details
CVE-2016-5841
Integer overflow in MagickCore/profile.c in ImageMagick before 7.0.2-1 allows remote attackers to cause a denial of service (segmentation fault) or possibly execute arbitrary code via vectors involving the offset variable.
CVE-2018-16328
In ImageMagick before 7.0.8-8, a NULL pointer dereference exists in the CheckEventLogging function in MagickCore/log.c.
CVE-2018-16329
In ImageMagick before 7.0.8-8, a NULL pointer dereference exists in the GetMagickProperty function in MagickCore/property.c.
CVE-2019-17547
In ImageMagick before 7.0.8-62, TraceBezier in MagickCore/draw.c has a use-after-free.
CVE-2019-13136
ImageMagick before 7.0.8-50 has an integer overflow vulnerability in the function TIFFSeekCustomStream in coders/tiff.c.
CVE-2021-20310
A flaw was found in ImageMagick in versions before 7.0.11, where a division by zero ConvertXYZToJzazbz() of MagickCore/colorspace.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick. The highest threat from this vulnerability is to system availability.
CVE-2021-20311
A flaw was found in ImageMagick in versions before 7.0.11, where a division by zero in sRGBTransformImage() in the MagickCore/colorspace.c may trigger undefined behavior via a crafted image file that is submitted by an attacker processed by an application using ImageMagick. The highest threat from this vulnerability is to system availability.
CVE-2021-20312
A flaw was found in ImageMagick in versions 7.0.11, where an integer overflow in WriteTHUMBNAILImage of coders/thumbnail.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick. The highest threat from this vulnerability is to system availability.
CVE-2021-20313
A flaw was found in ImageMagick in versions before 7.0.11. A potential cipher leak when the calculate signatures in TransformSignature is possible. The highest threat from this vulnerability is to data confidentiality.
CVE-2017-11447
The ReadSCREENSHOTImage function in coders/screenshot.c in ImageMagick before 7.0.6-1 has memory leaks, causing denial of service.
CVE-2020-25663
A call to ConformPixelInfo() in the SetImageAlphaChannel() routine of /MagickCore/channel.c caused a subsequent heap-use-after-free or heap-buffer-overflow READ when GetPixelRed() or GetPixelBlue() was called. This could occur if an attacker is able to submit a malicious image file to be processed by ImageMagick and could lead to denial of service. It likely would not lead to anything further because the memory is used as pixel data and not e.g. a function pointer. This flaw affects ImageMagick versions prior to 7.0.9-0.
CVE-2020-27829
A heap based buffer overflow in coders/tiff.c may result in program crash and denial of service in ImageMagick before 7.0.10-45.
CVE-2021-20243
A flaw was found in ImageMagick in MagickCore/resize.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero. The highest threat from this vulnerability is to system availability.
CVE-2021-20244
A flaw was found in ImageMagick in MagickCore/visual-effects.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero. The highest threat from this vulnerability is to system availability.
CVE-2020-27768
In ImageMagick, there is an outside the range of representable values of type 'unsigned int' at MagickCore/quantum-private.h. This flaw affects ImageMagick versions prior to 7.0.9-0.
CVE-2020-27769
In ImageMagick versions before 7.0.9-0, there are outside the range of representable values of type 'float' at MagickCore/quantize.c.

Scanned versions: nixos-21.05: 2262d7863a6.
Cc @erictapen

All CVE's were already handled in https://github.com/NixOS/nixpkgs/issues/124642.


[#112234445] Use correct argument for aws_route_table gateway

What
Change terraform/cloudfoundry/ to use the nat_gateway_id argument
instead of gateway_id because we're passing the ID of a NAT Gateway rather
than an Internet Gateway.
When creating or updating a route_table resource the AWS API will let you
use either argument interchangeably for either type of gateway. However,
when you read it back, it modifies it to the right argument. This causes
Terraform to think that the resource needs updating on every run.
I've started a discussion with upstream in hashicorp/terraform#6551 about
how this could be handled in a more explicit way.
 Resources: 0 added, 3 changed, 0 destroyed.

How to review

Checkout this branch: git checkout bugfix/112234445-terraform_route_table_flapping
Upload the pipeline to your environment: BRANCH=$(git rev-parse --abbrev-ref HEAD) make dev pipelines
Run the create-bosh-cloudfoundry pipeline.
Look in the output of the terraform-apply task in the cf-terraform job.
Confirm that it no longer contains the log lines mentioned about about modifying the aws_route_table resource.

Who can review
Not @dcarley

All good.


Missing XDG decoration results in missing window system controls

System:

OS Ubuntu 22.04.1 LTS
GNOME 42.4
Window System Wayland

Code
#include <assert.h>
#include <stdio.h>
#include "glad/gl.h"
#include <GLFW/glfw3.h>

void error_callback(int code, const char* description)
{
    printf("[E] [glfw] (code=%d) %s\n", code, description);
}

int main()
{
    GLFWwindow* window = NULL;

    glfwSetErrorCallback(error_callback);

    /* Initialize the library */
    if (!glfwInit())
        return -1;

    //glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

    /* Create a windowed mode window and its OpenGL context */

    window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
    if (!window)
    {
        glfwTerminate();
        return -1;
    }

    glfwMakeContextCurrent(window);

    if (!gladLoadGL((GLADloadfunc)glfwGetProcAddress))
    {
        printf("[E] [glad] gladLoadGL failed\n");
        return -1;
    }
    printf("[I] [gl]\n    Vendor: %s\n    Renderer: %s\n    Version: %s\n",
        glGetString(GL_VENDOR), glGetString(GL_RENDERER), glGetString(GL_VERSION));

    glfwShowWindow(window);

    /* Loop until the user closes the window */
    int tick = 0;
    while (!glfwWindowShouldClose(window))
    {
        /* Poll for and process events */
        glfwPollEvents();

        //printf("[I] update: %d\n", tick);
        tick += 1;

        glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
        glClear(GL_COLOR_BUFFER_BIT);

        glfwSwapInterval(1);
        glfwSwapBuffers(window);
    }

    glfwDestroyWindow(window);
    glfwTerminate();
    return 0;
}

ScreenShot:

Wayland Global:
[I] [wayland] global wl_compositor (v5)
[I] [wayland] global wl_drm (v2)
[I] [wayland] global wl_shm (v1)
[I] [wayland] global wl_output (v2)
[I] [wayland] global zxdg_output_manager_v1 (v3)
[I] [wayland] global wl_data_device_manager (v3)
[I] [wayland] global zwp_primary_selection_device_manager_v1 (v1)
[I] [wayland] global gtk_primary_selection_device_manager (v1)
[I] [wayland] global wl_subcompositor (v1)
[I] [wayland] global xdg_wm_base (v4)
[I] [wayland] global zxdg_shell_v6 (v1)
[I] [wayland] global gtk_shell1 (v5)
[I] [wayland] global wp_viewporter (v1)
[I] [wayland] global zwp_pointer_gestures_v1 (v3)
[I] [wayland] global zwp_tablet_manager_v2 (v1)
[I] [wayland] global wl_seat (v5)
[I] [wayland] global zwp_relative_pointer_manager_v1 (v1)
[I] [wayland] global zwp_pointer_constraints_v1 (v1)
[I] [wayland] global zxdg_exporter_v1 (v1)
[I] [wayland] global zxdg_importer_v1 (v1)
[I] [wayland] global zwp_linux_dmabuf_v1 (v4)
[I] [wayland] global zwp_keyboard_shortcuts_inhibit_manager_v1 (v1)
[I] [wayland] global zwp_text_input_manager_v3 (v1)
[I] [wayland] global wp_presentation (v1)
[I] [wayland] global xdg_activation_v1 (v1)

GNOME doesn't support XDG decoration. There is an open issue for implementing window decoration on desktop environments that don't support it via libdecor

Support for libdecor has now been added with #2285 and was included in the latest stable release.


Can't modify port

Describe the bug
I modified the port in the setting file of the api, and modified the port in the env in the pandora project, and the port was not modified when I finally ran it.And open the given website with only one nuxt logo, and click it to enter the official website of nuxt, Is there something wrong with me?
Expected behavior
A clear and concise des
cription of what you expected to happen.
Screenshots

Please describe your problem in more detail.The port in env is the port to connect to node-chatgpt-api, and the port of api can be set by yourself. The port of the website is fixed at 3000.Please visit your website address and give me a screenshot to let me know what problem you encountered.

Thank you, I have solved the problem now, I used to understand that if I changed the port of api and the website, the port of nuxt would be the same as them, it was my misunderstanding, it has been solved now, thank you again!!

Thank you, I have solved the problem now, I used to understand that if I changed the port of api and the website, the port of nuxt would be the same as them, it was my misunderstanding, it has been solved now, thank you again!!


Notebook Icon Overlaps with Indentation Lines in Explorer Viewlet

Indentation lines in the file explorer overlap with the notebook icon. May need to see if we can either make the icon smaller here, or add some padding.

Not able to repro this anymore, closing it.


Fix URI encoding for connection provider calls

Fixes https://github.com/microsoft/azuredatastudio/issues/14044
Fixes https://github.com/microsoft/azuredatastudio/issues/10259
See previous PRs for some more explanation of the issues :
https://github.com/microsoft/azuredatastudio/pull/13503
https://github.com/microsoft/azuredatastudio/pull/14299
Basically - we're putting the full file path URI in the "owner URI" fields to identify which file the query should be applied to. But previously we weren't encoding the paths here before parsing them as a URI - which meant that reserved characters such as %20 were getting turned into their mapped values (%20 -> a space for example) before being sent to the providers. They then wouldn't be able to find the file because there wasn't a file opened with those decoded values.
So instead we have to encode the URIs before we parse them to preserver the characters as they came in.
This did require a change in SQL Tools Service (https://github.com/microsoft/sqltoolsservice/pull/1189) to make sure all the parts were handling URIs in the same way.
Note that doing this does mean that any other connection providers may be broken if they had custom logic to handle this case. But since PG is the only major user of this extensibility that I'm aware of and this is a pretty big edge case I figured it was better to make these changes now.
Testing
I did lots of manual testing with various combinations of directory names and file names and didn't nothing anything too broken. I did start seeing a strange issue where the results for a query in the path with %20 in it wasn't showing up initially - if I switched to another tab and back it rendered properly though. I wasn't able to get a consistent repro on that so I figure I'll get this in and then continue looking into that since I want to get as much testing as possible in before our next release given the scope of this change.
I added some smoke tests to cover the scenarios of opening and executing both SQL queries and Notebooks with various types of paths. This did require updating the sqlite repo since there was a bug there with handling the new escaped URIs https://github.com/microsoft/azuredatastudio-sqlite/commit/8a478af7e099e4c7f7f29fee7c2e562c14ae28db

I just realized that my Notebook test is testing the Python kernel which wasn't the one hitting the issue here. So while still good to have I'll be adding tests for those as well (may do that as a follow up PR if people have started looking at this already by the time I finish them)

I'll fix the distro merge later

Pull Request Test Coverage Report for Build 757283198

0 of 13 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.0002%) to 43.606%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/api/common/extHostDataProtocol.ts
0
13
0.0%

Files with Coverage Reduction
New Missed Lines
%

extensions/import/src/wizard/pages/fileConfigPage.ts
1
73.46%

Totals

Change from base Build 756880208:
0.0002%

Covered Lines:
26252

Relevant Lines:
54999

💛  - Coveralls

Once the validations pass I'll merge in - I have some integration tests to validate the SQL connection scenario that I'll be doing in a separate PR.


Fixing lint check for ci

I'm not sure this was causing any issue with CI, but when running the yaml through the gitlab ci linter, it would fail with Error: coreos-calico-sep job: stage parameter should be moderator, unit-tests, deploy-gce-part1, deploy-gce-part2, deploy-gce-special.
With the test definition of
coreos-calico-sep:
  stage: deploy-gce-part1
  <<: *job
  <<: *gce

We'd define the appropriate stage for the test, but then the gce variables would get merged in. This would change stage from deploy-gce-part1 to deploy-gce.

ci check this

ci check this


Remove duplicate code in BlockingLoadBalancerClient

Remove duplicate code in BlockingLoadBalancerClient 😄

@Johnny850807 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@Johnny850807 Thank you for signing the Contributor License Agreement!

Will cherry-pick to avoid conflicts.

Merged within https://github.com/spring-cloud/spring-cloud-commons/commit/361a8c2baefd3f580cd11feb38337e8ea49e476a.

Oops, I missed it, thank you very much.


Publicize schema property

This was previously publicized in https://github.com/GraphQLSwift/Graphiti/pull/27, but it looks like it reverted back to private as of
https://github.com/GraphQLSwift/Graphiti/commit/5d0e93302505e6a28ea9ccbb7f9a78cc1a0f89ef#diff-866deecae21b5220ab43fa7ede45c86bR54. Was this intentional? I'm using it in conjunction with https://github.com/StevenLambion/GraphQLRouteCollection.

Repository update

Fixed by the last release.


Downloading iOS 9.3 Simulator does not proceed ahead from Xcode 8.1

I am trying to download iOS 9.3 Simulator from Xcode 8.1 But some times downloading fails due to time out but after using 4G Network I got authorization e error. I have iPhone 4S with iOS 9.3.5 version, so I want to test my app on my iPhone. As Xcode 8+ does not support iPhone 4S because it has lower deployment target so I have changed my Xcode's deployment target to iOS 9.3 from 10.1. That's why I am trying to download and install the iOS Simulator. Kindly share your ideas in this regard.

@jawaidahmed I'm not sure this question is related to the @buildasaur.


Fix typo

Fix a small typo in example.
Change Bathc to Batch

@fchollet Thanks for pointing those files out. I've now updated them as well.

Great, thank you for your help! It looks like the CI failed, how can it be rerun?

The failure is unrelated, we can merge.

Great, thank you for your help!


Add a more idiomatic way to define hashing

The current way of using True/False/None is confusing even to me.
I propose we use an Enum (probably just class on legacy Python) a la:
class Hashing(Enum):
    SMART = "smart"  # None → new default
    BY_ID = "by_id" # False
    WRITE_FOR_ALL = "write_for_all" # True
    WRITE_FOR_NONE = "write_for_none" # True, but the default on attr.ibs is False

The last two names are terrible of course.

I probably could be talked into depending on https://pypi.org/project/enum34/ on legacy Python.
Opinions?
P.S. Now while typing this out I realized that this could solve a long-standing complaint both I and many users have:  assuming you want an attrs-generated method based on a small subset of attr.ibs, you have to write a lot of hash|init|repr=False.  Ditching bools for enums would allow for that. 🤔   But let’s talk about that in a different ticket.

We should definitely do something to make the hashing behavior clearer.
I'm currently working on a PR to "fix" slots hashing behavior, and attr.s(hash=False) is really throwing me off.
The docs say nothing about what should happen when hash=False.
My personal understanding would be for attrs to do exactly nothing, we're saying do not touch __hash__. However this is complicated. I will demonstrate.
Assume a very simple class, with hashing disabled:
@attr.s(hash=False)
class A:
    a = attr.ib()

The equivalent of this class is: https://gist.github.com/Tinche/d8c1dadfaa3aa4618b736a61e752b3e1
Try pasting them both. The attrs one will be hashable, due to falling back to __object__.__hash__. The normal one will not be.
This is because in the normal class, the interpreter will see the __cmp__ and insert __hash__ = None. In the attrs class, the __cmp__ method isn't there when the class is defined; we put it into the class after the fact. So the interpreter won't touch __hash__ and it will fall through to object.
This is the root cause of why our slots behavior is different.

Yeah so that’s settled.
Ideas for better names for WRITE_FOR_ALL/NONE?  @glyph? @njsmith?
P.S.  the replacement/slots thingie explains a lot of my own confusion.

What functionalities are we aiming for exactly?
I'm guessing:

make hashable by generating a hash function based on attributes
make hashable, but attributes are opt-in instead of opt-out
make hashable by using identity-based hashing
make unhashable
delegate to an existing self.__hash__, whatever that may be

I don't really understand the original post, but regarding the cases that need to be supported: I think it helps narrow things down to remember that for any given __eq__ there are exactly two valid ways of defining __hash__. Either it must include exactly the same things that go in the __eq__ calculation, or else you have to set __hash__ = None. This is just a fact about the language; if you violate it then dicts stop working.
So if attrs is generating its own __eq__, then the only meaningful decision is "do you want this object to be hashable?", and right now the three answers are "yes" (True), "no" (False), and "guess" (None, meaning yes for immutable objects and no otherwise). (Except apparently the "no" case is buggy? I'm pretty sure that the intention was for cmp=True, hash=False to make an unhashable class.) And then on a per attribute level you can also say yes/no/guess, but I can't think of any time that "guess" is wrong; the other options just give you interesting ways to break your class.
And if attrs isn't generating its own __eq__, then not sure why it would ever want to generate a __hash__. If the user is taking responsibility for __eq__ then we should stay out of the way and give them the regular python behavior imo.

That said, I can see the case for having nicer shorthands for controlling which attribs go into the __eq__ calculation, like toggling it between opt-in and opt-out. But there's no reason to give __hash__ a separate set of toggles here; it should follow what __eq__ does.

Actually, you specifically asked for being able to fall back to hashing by ID – that’s why it’s in there. :)  And I think that’s a great and useful feature, so I’m not trying to push the blame in your direction – just reminding. :)
The point of this ticket isn’t really to invent new behaviors, it’s just making the existing ones more understandable.  Especially because one of the happened by accident (see also #205).
But maybe…how about this:
class Hashing(Enum):
    SMART = "smart"  # None → new default
    UNHASHABLE = "unhashable"  # same as None for unfrozen
    BY_ID = "by_id" # False
    BY_ATTRS = "opt_out" # True
    BY_ATTRS_OPT_IN = "opt_in" # True, but the default on attr.ibs is False

Falling back to hashing by id is definitely useful! If, and only if we are also falling back to doing __eq__ by id. That falls under my line about "If the user is taking responsibility for __eq__ then we should stay out of the way and give them the regular python behavior"

Yeah so the fallback kind of happened by accident (cf. Tin’s explanations) but this time we have the chance to fix it properly including the deprecation year if we switch to enums.

The thing where cmp=True, hash=False ends up with a generated __eq__ combined with __hash__-by-id just sounds like a straightforward bug to me. It just makes it so you can have two objects that compare equal but if you put them both into the same set then it's literally random whether you end up with 1 object added or 2 objects added.
Beyond that I'm mostly just kinda lost about what all these enums are supposed to be or what the overall goal is here. I think I showed up in the middle of the conversation :-)

So I guess we have to break bw-compat again and set hash to None by hand if eq is set? :|

So I guess we have to break bw-compat again and set hash to None by hand if eq is set? :|

Woah there, Tex.  Ease your finger up off that trigger :-).
In this case I'm not convinced a breaking change is necessary, because there's no alternate behavior to suggest: a warning would be sufficient.  The user has explicitly asked for nonsense, and if the nonsense appears to work today then it's fine to deprecate it for a while before raising an error.

Well the problem (which Tin explained elsewhere, I'm gonna add here for posterity) is: normal Python class behavior is setting dunder  hash to None, if there's an Dundee eq.  If not, it inherits object's by-id semantics.   Now our eq is added after python makes this decision (except when using slots) so object's hash remains.
If slots is true it behaves differently because we build the class differently and it becomes unhashable.
IOW

we have conflicting behavior between slotted and not,
and hash=False doesn't actually mean what it looks like (Don't do anything about hash.) because of a weird side-effect.

Dunno. :|

Now our eq is added after python makes this decision (except when using slots) so object's hash remains

Oh, that's deeply unfortunate.  I was wondering if the modifying-the-class-after-the-fact thing would come to bite us at some point; looks like it has.  Perhaps we should be throwing away the first type and replacing it with a fresh one?  (Although that's probably some even worse / more horrible compatibility break than this...)

and hash=False doesn't actually mean what it looks like (Don't do anything about hash.) because of a weird side-effect.

Focusing first on getting the exact right behavior with the new, good enum would be the right way to prioritize this. If we need another compat break (and gosh I hope not) then that's a separate thing.

JFTR, I started to work on this and ran into another “interesting” fact: the behavior Nathaniel described is specific to Python 3.  Python 2 will happily hash by ID if there's a __eq__.


Remove/obsolete AzureAppServicesDiagnosticsSettings.OutputTemplate

It's not used since we moved off Serilog.

We can deprecate it but it's a breaking change to remove it so lets not.

Yes. Let's put the attribute in preview2 @pakrym.


added: exchange fork pairs

Added exchange fork pairs as table in fork page.
Also cleaned up redundant repo and project_url links into _layout file.
Preview: https://brinkt.github.io/chainsplit-www/

@brinkt Looking good! Should we eventually add pairs against other cryptos besides BTC or against fiat? Seems like just against BTC is good for now.
Also, Bitstamp just added BCH support, perhaps we should add it before merging.


Suggestion: Give People Directory Results Same Experience in Results List as People Web Part

Category

[ ] Question
[ ] Bug
[x] Enhancement

Expected or Desired Behavior
Our executives love the People web part. They love that when we have a project site; the Project Managers put all the team members in on the home page and they can hover over them and get details, and pull up the org chart, and so on. They expect the same behavior from the results list in the People Directory, but are disappointed that it is so different. Believe it or not, this is actually a bit of an issue for our roll-out of hub sites as we'd like to use this webpart.

This would be a great enhancement. However, there isn't a supported mechanism for re-using the out of the box hover states as Microsoft hasn't provided an option for this yet. We are in the process of updating the people directory however to use the new Graph Toolkit.


KCP: Org, Project and stack lifecycle management

What would you like to be added?
CRUDL + Execute on project and stack
CRUDL on Org
Why is this needed?
KCP bootstrapping

Part of #872


Add Risingwave

Playground mode: https://www.risingwave.dev/docs/current/risingwave-docker-image/
Cluster: https://www.risingwave.dev/docs/current/risingwave-docker-compose/

closing, duplicate of #673


[Backport release-22.05] librewolf: 106.0.3-1 -> 107.0-1

Description of changes
Backport of #201358
(cherry picked from commit 9a2f7b878cb7ee63d6d7234bffa41e1e5c21f41a)

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

cc @mweinelt


Adding more authentication fields

Hi,
These days authenticating with email or mobile number are very common, I also use them. one solution to add these methods is to create custom authentication methods which gets username and search the username in other fields. certainly it's not a clean solution, a better approach would be adding more fields to mutation or letting users add they're own fields and they're own authenticators which takes those fields.

Hi @Glyphack ,
I'm sorry for the delay in my response.
I have created a PR #87 including an example to authenticate users using multiple fields.
If you have any questions, please let me know.

Hi @mongkok, after providing the custom_get_user_by_natural_key will the additional fields added reflect in the ObtainJSONWebToken function? I have pulled the code from master and it does not seem to be the case. Is there anything that I am missing on?

Hi @mongkok, after providing the custom_get_user_by_natural_key will the additional fields added reflect in the ObtainJSONWebToken function? I have pulled the code from master and it does not seem to be the case. Is there anything that I am missing on?

Hi @JSeam2 and I'm sorry for the delay in my response.
You can use a single input field and use that value to look up the user on different fields.
e.g.
USERNAME_FIELD = 'email'
Input field names:

email (USERNAME_FIELD), for username and email.
password

from django.contrib.auth import get_user_model
from django.db.models import Q

def custom_get_user_by_natural_key(username):
    User = get_user_model()
    try:
        return User.objects.get(Q(username=username) | Q(email=username))
    except User.DoesNotExist:
        return None

GRAPHQL_JWT = {
    'JWT_GET_USER_BY_NATURAL_KEY_HANDLER': custom_get_user_by_natural_key
}

I close the issue, if you have any questions please let me know.


Add a license

This repository doesn’t currently have a license. Adding one should clarify usage and distribution.
You can find a list of OSI-compatible licenses here: Open Source Initiative Licenses.

I added a license to the repository


Allow "Skip to Navigation" to be omitted

Hi there!
I noticed that the accessible-astro-starter template uses this library of yours to render skip links. I also noticed there's two of them:

Skip to navigation
Skip to main content

But on the deployed version of accessible-astro-starter, tabbing from initial page load lands on Skip to navigation, which when activated only skips 1 item (the Skip to main content link).
Could the Skip to navigation piece be optionally omitted? I'm going by the WebAIM advice that multiple skip links are usually unnecessary, and in the case of the starter template, we're only skipping past 1 item. (This would also require not rendering a list, since it would only have a single link in it.)
Would appreciate your thoughts. Thanks!

Hey @iansjk!
Thanks for submitting the issue 🙂 In all honesty, it has been on my mind to simplify the skip links for the exact reason you're giving in your example. It had been a single skip link some time ago when the component was still part of the starter template itself. Upon moving it to this separate component library, I thought it would make sense to provide a more broad usage of the component by also adding the skip to navigation (for more complex projects). I also noticed that upon moving it to a library the need would arise to include an option to emit the skip to navigation part, but that's where my time ran a little short at the time.
So taking all that in consideration, I think the best thing to do is to convert the component to have just the skip link to the content and remove the rendered list, that would serve most cases anyway 🙂
I'm having very little time available to work on the projects lately, but I'll get to them eventually! Thanks again @iansjk.


Explorer .gitignore integration considers git repo outside of workspace folder

Issue Type: Bug
I cloned xterm into vscode's node_modules and opened that folder, all files in the explorer are faded out despite being in an "inner" git repo.

VS Code version: Code - Insiders 1.41.0-insider (599c076d91be1374cf51004cec610f3bcaf4c9cd, 2019-11-22T07:19:06.796Z)
OS version: Darwin x64 18.7.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2200)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 3, 2

Memory (System)
16.00GB (0.20GB free)

Process Argv
-psn_0_11799360

Screen Reader
no

VM
0%

Extensions (15)

Extension
Author (truncated)
Version

vscode-svgviewer
css
2.0.0

EditorConfig
Edi
0.14.2

vscode-pull-request-github-insiders
Git
2019.11.2342

vscode-azureappservice
ms-
0.16.1

vscode-docker
ms-
0.8.2

vscode-language-pack-ja
MS-
1.40.2

remote-containers
ms-
0.85.0

remote-ssh-edit-nightly
ms-
2019.11.21120

remote-ssh-nightly
ms-
2019.11.21120

azure-account
ms-
0.8.7

vscode-typescript-tslint-plugin
ms-
1.2.3

debugger-for-chrome
msj
4.12.1

material-icon-theme
PKi
3.9.1

sort-lines
Tyr
1.9.0

vscode-todo-highlight
way
1.0.4

(2 theme extensions excluded)

cc @jrieken Did you hit this before?

🤷♂ the ignore-provider simply runs git check-ignore, no extra massage or anything like that

They are ignored by one repo yet not ignored by another... I guess we never did really do decoration deduplication.

They are ignored by one repo yet not ignored by another...

I'd say they are ignored then. I wouldn't know how to show UX for this otherwise - it would require something very SCM/git-specific that allows you to select the current repo.

Seems to not happen in a minimal test case? 🤔

That's 2 git repos with the outer one having this in .gitignore:
ignore.txt
test3


Remove most of the warnings in tests

Details
Removes most of the warnings created when running tests by updating LangChain tests to avoid deprecated functions and creating a pytest config file.

@jverre sorry, I've just noticed the PR after it was approved...
We are using pytest.ini files locally and store env variables for tests in them. Adding this file might break things.


Implement saved query substitution for S3 integrations

Description
Activates the queries workflow with some simple example queries. It turns out that queries had hard refs to the tables and data sources they're defined with, so I also had to implement the ability to swap them out by adding it to the integration building process.
Issues Resolved
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Going to have zombie lint failures, tracking issue #1363


libosmium: 2.14.2 -> 2.15.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libosmium/versions.
meta.description for libosmium is: '"Fast and flexible C++ library for working with OpenStreetMap data"'.
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.15.0 with grep in /nix/store/z9bypxyfw8hcj9z1yhr1sh2j8qdwfnwg-libosmium-2.15.0

directory tree listing: https://gist.github.com/dc057ca8d1e14e771fda84a96f99c650

du listing: https://gist.github.com/439e325390d7eda31cfb35a8983447f4

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)
2 package rebuild(s)
2 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
libosmium
osmium-tool

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/z9bypxyfw8hcj9z1yhr1sh2j8qdwfnwg-libosmium-2.15.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A libosmium https://github.com/r-ryantm/nixpkgs/archive/2bae825da1fa56d2361785132eaf1d8632e915dd.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/z9bypxyfw8hcj9z1yhr1sh2j8qdwfnwg-libosmium-2.15.0
ls -la /nix/store/z9bypxyfw8hcj9z1yhr1sh2j8qdwfnwg-libosmium-2.15.0/bin

cc @das-g for testing.

(osmium-tool 1.10.0 has been released by upstream past Monday.)

Yeah, with
diff --git a/pkgs/applications/misc/osmium-tool/default.nix b/pkgs/applications/misc/osmium-tool/default.nix
index 36e58cf5070..2b35cb77038 100644
--- a/pkgs/applications/misc/osmium-tool/default.nix
+++ b/pkgs/applications/misc/osmium-tool/default.nix
@@ -2,13 +2,13 @@

 stdenv.mkDerivation rec {
   name = "osmium-tool-${version}";
-  version = "1.9.1";
+  version = "1.10.0";

   src = fetchFromGitHub {
     owner = "osmcode";
     repo = "osmium-tool";
     rev = "v${version}";
-    sha256 = "1cwabjbrdpqbi2gl7448sgniiwwa73avi9l6pnvh4r0jia2wi5wk";
+    sha256 = "1balhz78nva0agmbp8n9vg8fhmdssnd9fjxj20bpw7b45mxhjc20";
   };

   nativeBuildInputs = [ cmake ];

osmium-tool builds fine and seems to work. (Tried osmium --version, osmium --help, osmium fileinfo --help, osmium fileinfo path/to/some.osh.pbf, osmium fileinfo --extended path/to/some.osh.pbf.)

@GrahamcOfBorg build osmium-tool

Thanks for checking it!


[Feature Request] Simple finance tracking

Checklist

[X] This issue contains only one feature request. I will open one issue for every feature I want to request.
[X] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
[ ] This feature is merely an UI/UX update.
[X] This feature is not going to conflict with many of the existing features/options.

Is your feature request related to a problem? Please describe.
I don't really have particular goals to save up money for, but there's not much options with fleshed out UI/UX like this app.
Describe the solution you'd like
The ability to store simple transactions of payments that happened (or may happen later). The stored data:

recipient;
amount;
date: optional for if it's a payment that is upcoming, otherwise defaults to current date;
category: a tag/label that can be user created;
note: can be empty.

This could be a separate page in the menu.
How will you/everyone benefit from this feature?
This would allow:

tracking finances, when you don't have any particular goals;
filter transactions: by dates, by recipient or by category, one can check where you spend money;
allow to see upcoming payments;
have statistics of past transactions.

Additional context
Do you accept Pull Requests so that maybe I could help/work on this feature in the app?

Yep, I'm always open for PRs, i think maybe we can switch from sidebar navigation to bottom navigation and add this feature as a seperate tab in bottom navigation view, what do you think?

Yeah that sounds like I had thought it could reached in the app. Though then it would be better to first implement issue #57

Closing due to inactivity and since it's mostly out of scope for this project.

Yeah, now that I thought about, it will be for the best if I'd rather try and make my own project for this type of app.


try to fix LaTeX equation

Works, see https://trixi-framework.github.io/Trixi.jl/previews/PR989/tutorials/adding_new_equations/nonconservative_advection/#Basic-setup

Oh… so the space after # cannot be omitted?
Is there a full introduction for the syntax of markdown used for the document page? (Currently I'm just guessing based on the existing code. )

https://fredrikekre.github.io/Literate.jl/v2/fileformat/, although it's not very explicit about this

OK, so we still have to guess…
From: Hendrik Ranocha
Date: 2021-11-27 14:12
To: trixi-framework/Trixi.jl
CC: xzczd; Comment
Subject: Re: [trixi-framework/Trixi.jl] try to fix LaTeX equation (PR #989)
https://fredrikekre.github.io/Literate.jl/v2/fileformat/, although it's not very explicit about this
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


🐛 Bug Report: If you previously saved a login/password in Firefox, it fills the recipient and password fields with these credentials

👟 Reproduction steps

Create an account on pingvin-share, and ask your browser to save the login/password
Choose a file to share
Click on share button
The browser has populated recipient email field with your previously saved login, and password field with your previously saved password
If you remove the email to set another one, Firefox adds a popover below it to suggest to use a saved login. This mostly hides the field that allows to add the e-mail address

👍 Expected behavior
You should be able to upload a file without any password, even if you saved a login/password for this pingvin-share instance. And without having to manaually remove the password
👎 Actual Behavior
For some reason, Firefox considers that the couple "email recipients"/"share password" should be filled with saved credentials. Hopefully there is a way to avoid that, with changes in the HTML content
NB: it's a follow-up of #367

I started this a while ago but didn't have time to follow up with it. #509

I noticed that as well, this is likely related to naming of the forms

Would you mind to test the stonith404/pingvin-share:development image and let me know if this is fixed?

the behaviour is the same as before

I confirm, same behavior for me too with stonith404/pingvin-share:development image

This leads to shares that are password protected accidentally in some cases where the password is the saved pw from the logged-in user

Thanks for testing. Maybe the issue is caused by the password input that is in the same form. I have added autoComplete="new-password" to this input. Would you mind to try again by pulling the development image again?

The latest development image is working for me! In the sense that Firefox does not fill the wrong fields any more.
It still fills my credentials in the login form, which is what is expected. But not in other fields (e-mail recipient and password)
Many thanks

Don't hesitate to ask for more testing if you need to figure out if it comes from distinct forms or autoComplete="new-password"

i can confirm that the username/account is not inserted in the share dialogue

Thanks for the testing. The is fixed in the latest release.


Add Blockchain logo to gold sponsor section on summit page

Add Blockchain logo to gold sponsor section on summit page.
http://blockstack.org/summit

Complete


azmi getsecret hangs indefinitely if machine has no managed identity

The expected result is should fail right away with an appropriate error message. Currently it hangs and grabs system resources.

Bug fix implemented, waiting for release 0.4.1

New version released to public places.