text:
Publish a Windows image for each supported Java version

What feature do you want to see added?
It would be nice to publish Windows images for each supported Java version, as since #1773 only a jdk17 image is published.
Related:

https://github.com/jenkinsci/jep/pull/400

Upstream changes
No response

As tests are currently run sequentially, I've kept only the JDK17 and the JDK11 in #1770 to not increase build time too much.
Note: the container images publication on trusted.ci.jenkins.io skips tests so no publication time increase.

As far as I know, this has been completed by

#1820

authors: MarkEWaite lemeurherve

repo: jenkinsci/docker


text:
Enable Release Drafter to track changelogs in packaging versions

I suggest adding experimental changelogs to the Docker packaging. Why? Docker packaging is as important as Jenkins core itself. Even if we follow the "continuous delivery" approach for Weekly releases, some changelogs could help users to track changes.
How would it work?

We introduce meta-releases by adding GitHub tags
We periodically cut new releases when we feel there is enough content
Weekly releases just use the master branch and pick the latest version
TBD: LTS packaging uses latest tags for packaging

WDYT @carlossg @batmat @slide ?

More information for users is a good thing. :+1: from me.

+1, this is awesome

Started a dev list Discussion about the versioning approach: https://groups.google.com/forum/#!topic/jenkinsci-dev/KvV_UjU02gE

Uh oh
[2019-07-24T04:19:03.548Z] [Pipeline] timeout

[2019-07-24T04:19:03.548Z] Timeout set to expire in 40 min

[2019-07-24T04:19:03.561Z] [Pipeline] {

[2019-07-24T04:19:03.608Z] [Pipeline] node

[2019-07-24T04:19:18.621Z] Still waiting to schedule task

[2019-07-24T04:19:18.621Z] Waiting for next available executor on ‘docker’

[2019-07-24T04:59:03.549Z] Cancelling nested steps due to timeout

[2019-07-24T04:59:03.561Z] [Pipeline] // node

[2019-07-24T04:59:03.594Z] [Pipeline] }

[2019-07-24T04:59:03.629Z] [Pipeline] // timeout

[2019-07-24T04:59:03.679Z] [Pipeline] End of Pipeline

[2019-07-24T04:59:04.261Z]

[2019-07-24T04:59:04.261Z] GitHub has been notified of this commit’s build result

[2019-07-24T04:59:04.261Z]

[2019-07-24T04:59:04.262Z] Timeout has been exceeded

[2019-07-24T04:59:04.262Z] Finished: ABORTED

#860 should fix it

I am going to merge it tomorrow if no negative feedback

https://github.com/jenkinsci/docker/releases/tag/jenkins-docker-packaging-2.176.2 for look&feel

Let's see how it flies in real

source: gharchive/pull-request

authors: markyjackson-taulia oleg-nenashev slide

license: MIT

license_type: permissive

license_source: github-api


text:
Test case

[ ] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[ ] Ensure that the pull request title represents the desired changelog entry
[ ] Please describe what you did
[ ] Link to relevant issues in GitHub or Jira
[ ] Link to relevant pull requests, esp. upstream and downstream changes
[ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

Test

repo: jenkinsci/pipeline-examples

license: mit

license_source: bigquery


text:
Update puppet_helper.groovy

Small typo fix

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

authors: VuokkoVuorinnen jenkinsadmin

repo: jenkinsci/puppet-jenkins


text:
stapler:bind is creating inline javascript

What feature do you want to see added?
using <st:bind var="myproxy" value="${it}"/>result in the following code getting injected in the rendered page:
<script>
myproxy = makeStaplerProxy(...)
</script>

This is a problem when Content Security Policy should be enabled.
Maybe  one can just create some json data
<script class="stapler-javascript-proxy" type="application/json">
  {"myproxy": {"url": "/jenkins/$stapler/bound/dcabcdd4-f80d-4b46-b5f7-db0ce94ab8ff",
               "crumb": "abc234d97ed766f5...",
               "methods": ["myfirstmethod", "mysecondmethod"]
               }
  }
</script>

The bind.js could then find the data and do the assignment to the variable.
Upstream changes
No response

There's a PR here for this https://github.com/jenkinsci/stapler/pull/385 from @daniel-beck

Merged and included in Stapler release 1839.ved17667b_a_eb_5

Depends on https://github.com/jenkinsci/jenkins/pull/6865 to work though. Reviews still welcome!

source: gharchive/issue

authors: MarkEWaite daniel-beck mawinter69 timja

repo: jenkinsci/stapler


text:
Home assistant addon migration: no devices with HMIP-RFUSB-TK

Describe the issue you are experiencing
After migrating from the official home assistant addon I don't see any homematic-ip devices.
Restoring the backup complains about a missing *.apkx file
Describe the behavior you expected
All my homematic-ip devices in the new addon
Steps to reproduce the issue

Create backup in old homematic addon
Stop old addon
install new addon
import backup

What is the version this bug report is based on?
3.61.7.20220115
Which base platform are you running?
ha-addon (HomeAssistant Add-on)
Which HomeMatic/homematicIP radio module are you using?
HmIP-RFUSB
Anything in the logs that might be useful for us?
Mounting /data as /usr/local (Home Assistant Add-On): OK
Identifying onboard hardware: oci, OK
Initializing RTC Clock: onboard, OK
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: OK: backup successfully restored
Initializing System: OK
Starting logging: OK
Init onboard LEDs: init, OK
Starting irqbalance: OK
Starting iptables: OK
Starting network: eth0: link up, fixed, firewall, inet up, 172.30.33.3, OK
Identifying Homematic RF-Hardware: ....HmRF: none, HmIP: HMIP-RFUSB-TK/USB, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 2.8.4=>4.4.16, ERROR (2.8.4 != 4.4.16); HMIP-RFUSB-TK: 2.8.4, OK
Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting ha-proxy: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled
Starting multimacd: not required
Starting rfd: no BidCos-RF hardware found
Starting HMIPServer: ............OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: OK
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK

Additional information
No response

Apart from the shown error message in your boot log (which was a false error message I just fixed with bc2693a), I think you ran into the same issue like #1671 where the whole device list was shown empty in 3.61.7.20220115 in case no bidcos rf capable rf module was used. This has already been fixed for the next version. So please have a look if your hmip devices show up in the room/function lists and are just missing in the global device list. If so, this is the same issue like #1671.

I've tried again with the snapshot image.
Home assistant log doesn't show any errors anymore.
I don't see any devices in room/functions
This is the last part of the downloadable log:
{"000A1BE98A07F7:0","LOW_BAT",0}, result: [faultCode:-2,faultString:"Invalid device"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: XMLRPC 'reportValueUsage' call failed (interface: 1008, params: {"000A1BE98A07F7:0","LOW_BAT",0}) [CallReportValueUsage():iseXmlRpc.cpp:1676]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id = 1279 [RemoveDPFromCollections():iseManageDP.cpp:439]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.warn ReGaHss: WARNING: XMLRPC 'reportValueUsage': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"000A1BE98A07F7:0","INSTALL_TEST",0}, result: [faultCode:-2,faultString:"Invalid device"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: XMLRPC 'reportValueUsage' call failed (interface: 1008, params: {"000A1BE98A07F7:0","INSTALL_TEST",0}) [CallReportValueUsage():iseXmlRpc.cpp:1676]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id = 1278 [RemoveDPFromCollections():iseManageDP.cpp:439]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.warn ReGaHss: WARNING: XMLRPC 'reportValueUsage': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"000A1BE98A07F7:0","DUTY_CYCLE",0}, result: [faultCode:-2,faultString:"Invalid device"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: XMLRPC 'reportValueUsage' call failed (interface: 1008, params: {"000A1BE98A07F7:0","DUTY_CYCLE",0}) [CallReportValueUsage():iseXmlRpc.cpp:1676]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id = 1277 [RemoveDPFromCollections():iseManageDP.cpp:439]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.warn ReGaHss: WARNING: XMLRPC 'reportValueUsage': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"000A1BE98A07F7:0","CONFIG_PENDING",0}, result: [faultCode:-2,faultString:"Invalid device"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: XMLRPC 'reportValueUsage' call failed (interface: 1008, params: {"000A1BE98A07F7:0","CONFIG_PENDING",0}) [CallReportValueUsage():iseXmlRpc.cpp:1676]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev local0.err ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id = 1273 [RemoveDPFromCollections():iseManageDP.cpp:439]
Jan 28 11:36:29 de838cd8-raspberrymatic-dev user.debug hm_deldev: event fired (delete 000A1BE98A07F7)
Jan 28 11:36:43 de838cd8-raspberrymatic-dev user.warn monit[618]: 'hasUSB' status failed (1) -- no output
Jan 28 11:36:44 de838cd8-raspberrymatic-dev user.warn monit[618]: 'rpi4usb3Check' status failed (1) -- no output
Jan 28 11:36:44 de838cd8-raspberrymatic-dev user.err monit[618]: Filesystem '/media/usb1' not mounted
Jan 28 11:36:44 de838cd8-raspberrymatic-dev user.err monit[618]: 'usb1' unable to read filesystem '/media/usb1' state
Jan 28 11:36:44 de838cd8-raspberrymatic-dev user.info monit[618]: 'usb1' trying to restart
Jan 28 11:36:59 de838cd8-raspberrymatic-dev user.warn monit[618]: 'hasUSB' status failed (1) -- no output
Jan 28 11:37:00 de838cd8-raspberrymatic-dev user.err monit[618]: 'rpi4usb3Check' status failed (1) -- no output
Jan 28 11:37:00 de838cd8-raspberrymatic-dev user.err monit[618]: Filesystem '/media/usb1' not mounted
Jan 28 11:37:00 de838cd8-raspberrymatic-dev user.err monit[618]: 'usb1' unable to read filesystem '/media/usb1' state
Jan 28 11:37:00 de838cd8-raspberrymatic-dev user.info monit[618]: 'usb1' trying to restart
Jan 28 11:37:16 de838cd8-raspberrymatic-dev user.warn monit[618]: 'hasUSB' status failed (1) -- no output
Jan 28 11:37:16 de838cd8-raspberrymatic-dev user.err monit[618]: Filesystem '/media/usb1' not mounted
Jan 28 11:37:16 de838cd8-raspberrymatic-dev user.err monit[618]: 'usb1' unable to read filesystem '/media/usb1' state
Jan 28 11:37:16 de838cd8-raspberrymatic-dev user.info monit[618]: 'usb1' trying to restart
Jan 28 11:37:32 de838cd8-raspberrymatic-dev user.err monit[618]: 'hasUSB' status failed (1) -- no output

***** hmserver.log *****
Jan 28 11:35:54 de.eq3.cbcs.server.core.vertx.KeyServerWorker ERROR [vert.x-worker-thread-1] Missing key server configuration parameter (Network.Key) for  mode: KEYSERVER_LOCAL

I've looked for this and https://github.com/jens-maus/RaspberryMatic/issues/613 seems related but already fixed.

The issue seems to be that the backup migration has still a bug for which I already submitted a PR for integration (https://github.com/home-assistant/addons/pull/2366). So please wait until there will be a new HomeMatic CCU Add-on version (99.0.3) which hopefully will fix your backup import issues here.

@jens-maus  does it mean backups before tv99.0.3 will be broken and can't be imported?
Currently in the migration and the old addon is already removed :|

@jens-maus does it mean backups before tv99.0.3 will be broken and can't be imported? Currently in the migration and the old addon is already removed :|

Well, it means that this is the reason why homematicIP devices are missing (as stated here). So if you have missing homematicIP devices, restore your homematic add-on backup, wait for 99.0.3 and then redo the backup export.

The 99.0.3 old homematic ccu add-on had just been released yesterday. So please retry to export a sbk backup with that version and then report back here if HmIP device are correctly imported in the RaspberryMatic add-on afterwards.

@jens-maus with the new version I get following error when creating the backup.
An internal error was detected in the service software. The diagnostics are being emailed to the service system administrator (root).
The log part is not spiting out any useful hint, complains about a missing mail relay. :-| any idea?

I've looked into this and am fairly sure this is the remaining fix: https://github.com/home-assistant/addons/pull/2371
I created a backup with that fix applied and now have my homematic devices in raspberrymatic. 🎉
Thanks @jens-maus for the project!

hm, for some reason it still doesn't work. I will investigate more later

hm, for some reason it still doesn't work. I will investigate more later

What exactly does not work? Please be more precise. You said, with the fixed backup your homematic/homematicIP devices are in RaspberryMatic now. So what actually does not work?

@jens-maus so I tried it again, the backup is created but the restore is failing. See the attached screenshot.

@Nokius Try to ignore that message and reboot the Add-on right away. Then have a look if everything is back. This error can occur if you don't have any homematic rf module connected to the Add-on while restoring the backup.

What exactly does not work? Please be more precise. You said, with the fixed backup your homematic/homematicIP devices are in RaspberryMatic now. So what actually does not work?

Sorry, I wasn't sure what the issue was and didn't have time.
I thought the backup was fixed, because after importing a backup and restarting i saw devices in the homematic list.
These devices apparently disappear after a while.
It seems that my fix for ignoring mv error codes was not a good idea. I've now logged in docker exec and tested a better solution and will create a new pull request in a couple of minutes. I've now actually got devices in homematic. (checked by triggering boost)

@Nokius I saw there is 99.0.5 in the pipeline. The restore didn't work. nothing was imported. :crossed_fingers:  that all will work with the new release :)
Thanks for all the work!

need to wait a little bit more...
tried reboots not sure there is a way to force a check for new versions...
- description: HomeMatic central based on OCCU
  icon: true
  logo: true
  name: HomeMatic CCU
  repository: core
  slug: core_homematic
  state: started
  update_available: false
  version: 99.0.4
  version_latest: 99.0.4

@jens-maus the backup was completed and a restore was working as well I see my devices again.
Looking into the HA -> raspberrymatic communication now :D
Thanks!

@jens-maus all worked very well, may the documentation for the "Add a home assistant automation to connect to the raspberrymatic addon" could be improved a little. It toke me a few attempts to figure out how to set up the program/script.
Own you more then one beer, will ping you when I'm around Dresden next time.

@jens-maus all worked very well, may the documentation for the "Add a home assistant automation to connect to the raspberrymatic addon" could be improved a little. It toke me a few attempts to figure out how to set up the program/script.

Feel free to edit the documentation yourself. That's exactly why this is a wiki!

if I do so the preview is missing the images :(

authors: Nokius jens-maus sdirkwinkel

repo: jens-maus/RaspberryMatic


text:
S.USV - Hardwareversion 1.0 not working

Hi,
since a couple of version  after a reboot/update it takes  a very long time to system comes up.
Today i update to the last version and here the same thing.
Now i analyzed the problem: The system hangs on the init-script for the s.usv-daemon (S51susvd).
Here is the susv-client the one who stalles on getting information from the usv-board.
I have the hardware-version 1.0 and it seems that on this version the susv-client from version 2.0 is not working. So i checked the init.script and there is a check for getting the firmware version. But it looks like that the susv-client only work on HW 2.0.
So the scripts checks only with susv and than stalls on HW 1.0. Here should timeout be used to kill the process after a couple of seconds and then if no version was found the check should be done again with the susv1 client.
The timeout command seems  not in the raspimatic-distribution.
I hope the problem is clear.
Kind regards Thorsten

This problem is more or less already known. See here:
https://homematic-forum.de/forum/viewtopic.php?f=65&t=39482&start=350#p427524
The problem is, that Olmatic hasn't released a new firmware for the V1 hardware boards to properly support to identify these boards so that during startup the correct firmware will be flashed and thus the correct client/daemon used.
As Olmatic stated, they are about to release a new firmware for the V1 hardware boards including a unified client/daemon for both hardware versions (see https://homematic-forum.de/forum/viewtopic.php?f=65&t=39482&start=360#p427977)
Let's see how long this will take. For the time being, I am afraid but there isn't a smooth solution and you would have to manually modify your /etc/init.d/S51susvd script to directly start the susv1 client binary instead.

Ok, thank's for your quick response ... i changed the init-script and for me it's a good workaround .....

New Firmware (V1.40) is here
https://s-usv.de/files/firmware/susv_fw_14_pi.tar.gz

@Gluehwurm All these firmware files are already delivered with the latest RaspberryMatic version (see /opt/susvd/fw). Thus, all a user would have to do is to use the firmware update command to update their S.USV using the well known susv update command in a SSH session.

This issue has been marked obsolete because time has passed and the content/topic of the issue seem to be not relevant anymore or does not match the current state-of-affairs. Thus, the issue had been closed. If you feel it is still relevant, please update the ticket accordingly with newer information and explain why you feel it is still relevant and should still be taken care of.

authors: Gluehwurm Kroki0815 jens-maus


text:
Ensure hair_trigger ActiveRecord settings run after app load

This PR addresses the problem of ActiveRecord::Base being called prior to a Rails apps own initializers being loaded. It manifested specifically in an inability to set Rails.application.config.active_record.belongs_to_required_by_default = true during our Rails 5 upgrade.
The fix is basically cribbing this fix right here: https://github.com/ankane/ahoy/issues/213 when the issue was seen in another gem.

released in v0.2.24

authors: dhnaranjo jenseng


text:
Local Time vs Server Time and Astronomical Phenomenon

I see in issue #80 the discussion of the configuration file, that being a case in which the server is in a different location (like a cloud provider) but your use case local timezone differs from the remote server time. The setting of the timezone field in the configuration works for me. So, I request an event at 8:45 PM and it performs as scheduled, the node compensating for the time shift. My issue is with the sun position calculations.
My use case is in America/New_York but my server is 4 hours ahead in Reykjavik. Sunrise tomorrow (locally in New York) is at 7:26, but when I use the pull down menu to assign sunrise the 'next event at . . ." time is 11:26. (NY + 4). I am not sure  if the issue is that the 'next event at . . .' note is wrong or if the module is computing sunrise in New York based upon the server time.
I have the correct latitude and longitude in the configuration, confirmed by Open Street Map. I will set an event for sunrise tomorrow and see when/if it triggers, so I will know more in a day and report back.

Yes, to confirm, local sun position calculations are calculated with reference to the timezone of the remote server, even if one specifies the local time zone for the server to utilize in the configuration file.

Hi @nanofortran, currently I cannot explain this because also for the sun an moon times, the node should shift the time according to the configured time zone. Can you please double check that you really entered the NY time zone in the configuration node (the latitude and longitude coordinates have no influence on the time zone, they are solely used for the geographic position that is needed for sun/moon time calculation).
Regards, Jens

Jens:
Yeah, pretty sure the timezone in the config file is correct, I have typed in "America/New_York". When I remove this, leaving the field blank, the node defaults back to the server's time in Iceland, when I add it back in I am on EST again. This change takes place after I re-Deploy. However, the sunrise (and other ephemera) are time shifted to that of the server. So, yes, the sunrise is computed correctly for the latitude and longitude, but it is time shifted to the server's timezone.
Thanks,
nf

Problem should be fixed with release 1.18.3. Feel free to re-open the issue if you still encounter problems, thanks.

Rock and roll, that looks good. Thank you.

authors: jensrossbach nanofortran

repo: jensrossbach/node-red-contrib-chronos


text:
Laravel 5.2 auth fail

[Symfony\Component\Debug\Exception\FatalErrorException]
Call to a member function getDateFormat() on null

## For Laravel 5.3
**Call to a member function getDateFormat() on nul**

Use another name of model **User.php**, example **UserMongo.php**

```php

<?php

namespace App;

use Illuminate\Notifications\Notifiable;
use Illuminate\Auth\Authenticatable;
//use Illuminate\Database\Eloquent\Model;
use Illuminate\Auth\Passwords\CanResetPassword;
use Illuminate\Foundation\Auth\Access\Authorizable;
use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract;
use Illuminate\Contracts\Auth\Access\Authorizable as AuthorizableContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;

use App\ModeloBase as Base;

class UserMongo extends Base implements AuthenticatableContract, AuthorizableContract, CanResetPasswordContract {

    use Authenticatable,
        Authorizable,
        CanResetPassword;

    use Notifiable;

    /**
     * The database table used by the model.
     *
     * @var string
     */
//    protected $table = 'users';

    protected $collection = 'users';

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [

        "name",
        "email",
        "password"

    ];
    protected $guarded = [

    ];

}
```

repo: jenssegers/laravel-mongodb


text:
Android Analysis Failure

From the google group an analysis failure was identified with a reproducible test case:
export ANDROID_HOME=$HOME/android-sdk  # Adjust path if needed. On Windows, use “set” instead of “export”.
# if you don't have Android SDK, you can download it from https://developer.android.com/studio/index.html#command-tools (on any platform) or via the following command (on Linux and MacOS)
(mkdir $ANDROID_HOME && cd $ANDROID_HOME && wget "https://dl.google.com/android/repository/sdk-tools-$(uname  | tr '[:upper:]' '[:lower:]')-3859397.zip" -O sdk.zip && unzip sdk.zip && rm sdk.zip)
# Now, accept all licenses unless you have done so
$ANDROID_HOME/tools/bin/sdkmanager --licenses

git clone https://github.com/v6ak/dependency-check-gradle-android-crash-sample
cd dependency-check-gradle-android-crash-sample
# The build.gradle has disabled autoupdate, but in clean environment, you have to enable it.
# You can use gradle 4.1 instead of gradlew.
./gradlew --stacktrace --info dependencyCheckAnalyze

FYI, I think this is a dupe of #974

authors: jebstuart jeremylong

repo: jeremylong/DependencyCheck