I am trying to report what I believe is an issue with RPMfusion.org repository, regarding the build of VLC therein.
Since the repository has hundreds of packages thereon, there seems to be nobody who wants to claim ownership of items posted there.
Rémi Denis-Courmont #Courmisch · 4 minutes ago Maintainer
Sorry but this is not a suitable venue to report issues with RPMfusion.org, which people here have zero control over.
After several attempts at emailing individuals at RPMfusion.org, I tried posting the issue as an issue in the code repository at videolan.org and got my finger smacked again.
My issue is that hundreds of downloads from the repository are getting a version of VLC that cannot properly play DVD menus. This only happens for those using the repository, so that rules out Windows and other non-RPM repositories.
I have about three pages of screenshots and instructions to quickly reproduce the problem. I think it may be a build issue, but cannot prove that to be the case.
Videolan.org doesn't want it: https://code.videolan.org/videolan/vlc/-/issues/27030#note_328247
RPMfusion.org by emails tell me "it is a package maintainer issue", and they don't want it. [[private emails]]
Anyone know anyone who might know who maintains VLC on RPMfusion.org??? Or where I might best post that question to reach a proper audience?
There is a VLC tag here, but not an "RPMfusion" one.
Thank you.
Related
I submitted my first pull request to the Apache Flink project on github, but the Travis CI check is saying two of the tests it ran have failed. The thing is that where it says the failures are occurring is in a module that I haven't modified at all. So what am I missing? I am very new to Travis CI as well, so I could just be reading something the wrong way, but I doubt it.
Here is the pull request on Travis CI: https://travis-ci.org/apache/flink/builds/368327990
The module I made changes to was Flink-connector-cassandra and the failure is happening in the module flink.
Thanks for any help in advance!
Actually such problems should be asked on the dev# mailing list of the corresponding project and not on Stackoverflow. Sometimes builds are not stable and thus tests might fail even though you have nothing to do with them. In most cases there exists already an issue in the corresponding bug tracker that mentions the test instability. If the community says everything is fine, you can still open your PR.
However, in your case you have "Too many files with unapproved license" which clearly indicates a mistake on your side. You need to add an Apache License header to your newly created files.
I want to display non-code differences between current build and the latest known successful build on Jenkins.
By non-code differences I mean things like:
Environment variables (includes Jenkins parameters) (set), maybe with some filter
Version of system tool packages (rpm -qa | sort)
Versions of python packages installed (pip freeze)
While I know how to save and archive these files as part of the build, the only part that is not clear is how to generate the diff/change-report regarding differences found between current build and the last successful build.
Please note that I am looking for a pipeline compatible solution and ideally I would prefer to make this report easily accessible on Jenkins UI, like we currently have with SCM changelogs.
Or to rephrase this, how do I create build manifest and diff it against last known successful one? If anyone knows a standard manifest format that can easily be used to combine all these information it would be great.
you always ask the most baller questions, nice work. :)
we always try to push as many things into code as possible because of the same sort of lack of traceability you're describing with non-code configuration. we start with using Jenkinsfiles, so we capture a lot of the build configuration there (in a way that still shows changes in source control). for system tool packages, we get that into the app by using docker and by inheriting from a specific tag of the docker base image. so even if we want to change system packages or even the python version, for example, that would manifest as an update of the FROM line in the app's Dockerfile. Even environment variables can be micromanaged by docker, to address your other example. There's more detail about how we try to sidestep your question at https://jenkins.io/blog/2017/07/13/speaker-blog-rosetta-stone/.
there will always be things that are hard to capture as code, and builds will therefore still fail and be hard to debug occasionally, so i hope someone pipes up with a clean solution to your question.
My friend and I are creating an app and we are wondering if there is a way where we can both edit the code at the same time?
Don't use SVN. You will see how easy version control could be and later everywhere on the job people will use Git because it is "better" and you will get frustrated.
Just use Git from the beginning, stay happy, you will love it. Really! 😏
The default in Xcode is Git too, so it can't be wrong.
Just be aware that the interface in Xcode is offering you a filtered version of the Git commands. As soon as you really need it for anything you will end up on the command line.
Whatever you try there, the first few times it will fail until you have learned the propper syntax and all side effects. So just make a copy of the folder, or zip or tar it before you try it a simple git command.
Also SourceTree is nice, but same problem there, learn what every command really does.
Use git! Lets people edit code and track the progress of the project (among many other useful tools).
Git Tutorial
If you are looking for more of a 'Google Docs' atmosphere, I would look into Codr or Cloud9
You can use SourceTree a free git repository handler.
I want to be able to see (in VS2013 UI) till which change-set I updated my files.
The reason I ask this is because of the following scenario:
I created a fix, checked it in and continued working on something else. One day later, my colleague is testing the bug I solved but found it unsolved. Next, I tried to reproduce it at my machine but was not able to do so. So I wondered whether my colleague got the latest version before starting to test, he was convinced he did, but we cannot find a way to see on what change-set he is.
It is important for us to know this information without getting the latest version and retest it. Since the testing procedure for this bug takes quite some time, and time is valuable.
I'm quite new to TFS and we just switched from SVN to TFS. At SVN, using tortoise, the revision of the local working copy was highlighted, so the user knew which revisions he missed or was at.
I would like to be able to get this same information via VS2013.
I searched the web and found this other question but it uses the command line and I want to see it in the UI. Beside that, I couldn't get the command to work.
The question: Where can I find the number of the change-set in the VS2013 user-interface, my local working copy is on?
One place I know of is in the source control explorer window of Visual Studio.
1: right click a file and go to Advanced->Properties
2: Under the general tab you will see "Workspace Version #" and "Latest Version #"
In the Source Code Explorer you should have a column for "latest". This will tell you at a glance if you have the latest or not.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.